Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-105

Text File | 1995-12-31 | 211.9 KB | 5,333 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 25 Jul 95       Volume 3 : Issue 105

Today's Topics:

        BlockMove replacement?
        Can ResEdit or Resorcerer generate ID header file?
        Components and A5
        Converting a string with numbers to an integer?
        Does anyone have code to get Ethernet Address?
        FutureBasic Mailing List?
        How do you write 'TMPL' resources?
        How much of a sound has played so far?
        How to "rubber bands"?
        How to use TSM floating windows?
        Standalone Code Resources
        Which sndCommands are safe at interrupt time?
        Why fuss over OpenDoc?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Sean Howard)
Subject: BlockMove replacement?
Date: Mon, 26 Jun 1995 16:27:26 -0400
Organization: FSU Academic Computing & Network Services

  Ok, I want to know if there is a way to either speed BlockMove
up considerably, or a way to do what it does completely bypassing
it.  I've heard of BlockMoveData, but THINK C 5.0 (I know, I'm
saving up) doesn't recognize it as a function.  I'd really like
to learn assembly, but can't find any material on it.  If some-
one could post or email an asm routine that does exactly what
BlockMove does with less overhead I'd be forever thankful.

  For those of you that care, I'm tring to write a game using
a sort of RLE type coding of graphics for the sprites. This
would allow me to perform a number of functions (scaling, clip-
ping, reversing,etc...) with less effort, and hopefully faster.
Only problem is BlockMove makes it slower than CopyMask, at least
I think it is BlockMove.

      Sean Howard
      [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steve Caine)
Date: Tue, 27 Jun 1995 01:00:57 GMT
Organization: The World @ Software Tool & Die

In article <[e-mail]>, [e-mail]
(Sean Howard) wrote:

>   Ok, I want to know if there is a way to either speed BlockMove
> up considerably, or a way to do what it does completely bypassing
> it.  I've heard of BlockMoveData, but THINK C 5.0 (I know, I'm
> saving up) doesn't recognize it as a function.

BlockMoveData is essentially the same code as BlockMove except that it
doesn't flush the instruction caches on 68040 machines. It calls the same
trap as BlockMove, but an extra bit is set that only later versions of
System software recognize; earlier versions treat BlockMoveData the same
as standard BlockMove.

You say THINK C 5 doesn't recognize BlockMoveData as a function. Probably
all you need to do is steal a function prototype from a later version of
Apple's headers, such as:

#pragma parameter BlockMoveData(__A0, __A1, __D0)
extern pascal void BlockMoveData(const void *srcPtr, void *destPtr, Size
byteCount)
= 0xA22E;

to match the following already in the Mac #includes folder:
#pragma parameter BlockMove(__A0,__A1,__D0)
pascal void BlockMove(const void *srcPtr,void *destPtr,Size byteCount)
    = 0xA02E;

You might try writing your own BlockMove that does long-to-long copying of
data except for the few bytes on either end that aren't long-word aligned.
A little assembly, and knowing you're running on 68040 machines, could
take advantage of the 16-byte copy instruction the '40 offers; I'm not an
assembly guru to say just what that would look like.

--
Steve Caine
Cascade Systems Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Wed, 28 Jun 1995 23:35:55 -0700
Organization: ErsteSoft

In article <[e-mail]>, [e-mail]
(Sean Howard) wrote:

>   Ok, I want to know if there is a way to either speed BlockMove
> up considerably, or a way to do what it does completely bypassing
> it.  I've heard of BlockMoveData, but THINK C 5.0 (I know, I'm
> saving up) doesn't recognize it as a function.  I'd really like
> to learn assembly, but can't find any material on it.  If some-
> one could post or email an asm routine that does exactly what
> BlockMove does with less overhead I'd be forever thankful.

Don't bother. Except on very small blocks of data (under 12 bytes or so),
you just aren't going to be able to beat BlockMove. It's already optimized
to within an inch of its life. And since it's in the ROM, and the ROM is
machine-specific, it can use the best instructions for the current
processor (even MOVE16 on the 68040) without having to take the time to
ask what processor that might me. The only inefficiency is in the trap
overhead to get there.

>   For those of you that care, I'm tring to write a game using
> a sort of RLE type coding of graphics for the sprites.

Do you mean you're using BlockMove to do the RLE expansion? That means
you're moving very small pieces of data most of the time. You'd be better
off just copying the data with the normal C idioms:  while (cnt--) *dest++
= *srce++;  for example.

> This
> would allow me to perform a number of functions (scaling, clip-
> ping, reversing,etc...) with less effort, and hopefully faster.
> Only problem is BlockMove makes it slower than CopyMask, at least

BlockMove and CopyMask are for different problem areas. BlockMove is for
moving contiguous chunks of arbitrary data from one place to another.
CopyMask is for moving pixels from one image to another. An image is
generally not contiguous, and has to take into account things like pixel
depth, rowBytes, clipping, other graphics-related issues. BlockMove has
nothing to do with graphics.

> I think it is BlockMove.

Maybe not. Why don't you check, and get back to us?

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Fri, 30 Jun 1995 19:38:23 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>,
Ron Hunsinger <[e-mail]> wrote:

>Don't bother. Except on very small blocks of data (under 12 bytes or so),
>you just aren't going to be able to beat BlockMove. It's already optimized
>to within an inch of its life. And since it's in the ROM, and the ROM is
>machine-specific, it can use the best instructions for the current
>processor (even MOVE16 on the 68040) without having to take the time to
>ask what processor that might me. The only inefficiency is in the trap
>overhead to get there.

I used to think this until I wrote a tool to compare the efficiency of
_BlockMove and _BlockMoveData to the standard ANSI routines memmove
and memcopy.  The results were a bit surprising: on my Quadra 800, the
MPW implementations of memmove and memcopy were signficantly faster
than _BlockMove(Data) for block sizes up to about 2k.  Of course, the
reverse was true when I turned on my PowerPC upgrade card, where
_BlockMove (which is implemented directly in the emulator) trounced
the emulated versions of memmove and memcopy.  Also, the performance
of memmove and memcpy is dependent on the particular implementation
being used.  The MPW versions of memmove and memcpy that I tested are
rather intelligent and use both longword moves and unrolled loops; the
last time I checked, the Symantec and Metrowerks versions of these
functions did simple byte moves and were considerably slower.

Chris.


+++++++++++++++++++++++++++

>From [e-mail] (shopsinm)
Date: 2 Jul 1995 16:08:28 GMT
Organization: Quill Program

I've written code using BlockMove on graphics with interesting results.
When I checked my codes custom blit against CopyBits in scrCopy mode
CopyBits was still faster for 32x32 pixmaps.  Apple has done some very
good optimization on their calls and I generaly find that for general
purposes I stick to Toolbox calls.  On the other hand I did get a good 30%
speedup over PlotCIcon by creating a GWorld and then calling CopyBits
twice with srcOr and xor.

--
Michael Falk Shopsin
[e-mail]

"If it's not on fire then it's a software problem."

+++++++++++++++++++++++++++

>From David A Lyons <[e-mail]>
Date: Fri, 7 Jul 1995 19:13:03 GMT
Organization: Apple Computer, Inc.

In article <scaine-2606952101340001@192.0.2.1> Steve Caine,
[e-mail] writes:

>BlockMoveData is essentially the same code as BlockMove except that it
>doesn't flush the instruction caches on 68040 machines. It calls the same
>trap as BlockMove, but an extra bit is set that only later versions of
>System software recognize; earlier versions treat BlockMoveData the same
>as standard BlockMove.

Perfectly true for 68K machines.  Two refinements if we include Power
Macintosh models:

(1) PowerPC code that calls BlockMove or BlockMoveData does not go
through the trap table at all.  These are just similar routines in
InterfaceLib.

(2) In general, the difference is whether you flush "the 68K
instruction cache" on a machine where there is one.  On a 68020/030,
the I-cache isn't big enough to be concerned about for a BlockMove,
and it always gets flushed.  On a 68040 it's worthwhile to avoid
unnecessary flushes, so BlockMoveData is helpful.

On a Power Macintosh 9500 (for example), there's a *much larger* 68K
instruction cache.  If you use BlockMove where you could have used
BlockMoveData, you'll be throwing away a large amount of PowerPC code
that had been dynamically compiled from 68K code, and that code will
have to get compiled again the next time it runs.

Dave Lyons
Mr Tangent

---------------------------

>From [e-mail] (Robert H Guttman)
Subject: Can ResEdit or Resorcerer generate ID header file?
Date: Wed, 21 Jun 1995 19:22:35 -0700
Organization: Arizona State University

My Question:

Does ResEdit or Resorcerer offer the option to generate a header
file (*.h) of resource IDs?


The History:

A while back, I did some Windows 3.1 programming using Borland C++.
[He pauses for the flames to subside...]  It contained a program
called (something like) Workbench that would let you define some
Windows resources that would later get linked in with the rest of
your code (if I remember correctly).  Anyway, one of the things
this application did was generate a *.h header file that contained
all of the IDs of the resources as #define directives.  All modules
that needed to access a resource would #include this header file
for the IDs.

This approach allowed me to define my resource IDs in one place
(in the resource editor) instead of both within the resource editor
and then again within my source code.  This was a "good thing".  If
I renamed one or more resources, I would get compile-time errors
(as opposed to run-time errors - a "bad thing") if my source code
didn't match up.  If I just renumbered some resources, I didn't
need to go back to modify any code.  Once the new header file was
generated, all references were updated automatically.

[The only down-side of this approach was that more modules needed
to be recompiled than was necessary.  However, my application was
small enough and the compiler fast enough that the benefit of this
approach outwayed any negative impact to the execute-fix-compile-
execute cycle. - IMHO]

I was disappointed not to see this capability in ResEdit.  Am I
missing something?  Does Resorcerer provide this capability?

Thanks in advance for any info.
- Rob Guttman
  home: [e-mail]
  work: [e-mail]
  Motorola GSTG, Scottsdale, AZ (USA)
  Artificial Intelligence Applications

+++++++++++++++++++++++++++

>From [e-mail] (Mark H. Linton)
Date: 23 Jun 95 09:06:28 EST
Organization: HRB Systems, Inc.

In article <[e-mail]>, [e-mail] (Robert H Guttman) writes:
> My Question:
>
> Does ResEdit or Resorcerer offer the option to generate a header
> file (*.h) of resource IDs?
>

I don't think so but it sure would be a great idea...

HELLO, IS ANYBODY LISTENING?

I do most of my work in Rez format (I like to be able to print out
and review my work--I guess everybody else just gets it right the
first time =^). Actually this is one of the reasons I still use SC
(I use CW also, but wish they had REAL Rez support). It is also
very convinient because the Rez file listens to my
ResourceDefinitions.h header for resource IDs, etc, while the
strictly graphical stuff (that I create with ResEdit, Resourcerer
is way to $$$, IMHO) is FIXED IN STONE, which makes it less than
portable from project to project.

An additional suggestion I might add would be to have Res*
ACTUALLY PAY ATTENTION to the *.h file and allow the use of
symbols instead of numeric constants in the definitions. This woud
get rid of the FIXED IN STONE problem as well.

--
Hope this helps.

Mark H. Linton
____________________________________________________________________
mark \'mdrk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG
marha boundary, L margo] 1 a : a conspicuous object serving as a guide
for travelers 2 : A standard or criterion of quality 3 : An object or
point that serves as a guide --idiom. mark time. 1 : To make little or
no progress

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 23 Jun 1995 17:08:54 GMT
Organization: Ecole Normale Superieure, Paris

In article <1995Jun23.090628.23402@hrbicf>,
Mark H. Linton <[e-mail]> wrote:

>> Does ResEdit or Resorcerer offer the option to generate a header
>> file (*.h) of resource IDs?
>
>HELLO, IS ANYBODY LISTENING?

Yup :-)

I have encountered the same problem. I would be willing to try and
write a small tool to do that. Something scriptable but without a user
interface, for instance.

We would have to agree on the format of the generated header files.
Something like

const ResType resty_<Name> = '<TYPE>';
const short   resid_<Name> = <ID>;

where <Name>, <TYPE> and <ID> are placeholders for the resource's
name, type and ID? Would that suit you? Let's discuss it. I might
then try to program the thing in my spare time.


--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Chris Thomas)
Date: Sat, 24 Jun 1995 18:47:55 -0800
Organization: Echo Software

In article <3sesf6$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

> In article <1995Jun23.090628.23402@hrbicf>,
> Mark H. Linton <[e-mail]> wrote:
>
> >> Does ResEdit or Resorcerer offer the option to generate a header
> >> file (*.h) of resource IDs?
> >
> >HELLO, IS ANYBODY LISTENING?
>
> Yup :-)
>
> I have encountered the same problem. I would be willing to try and
> write a small tool to do that. Something scriptable but without a user
> interface, for instance.
>
> We would have to agree on the format of the generated header files.
> Something like
>
> const ResType resty_<Name> = '<TYPE>';
> const short   resid_<Name> = <ID>;
>
> where <Name>, <TYPE> and <ID> are placeholders for the resource's
> name, type and ID? Would that suit you? Let's discuss it. I might
> then try to program the thing in my spare time.
>

What's the point of listing the type, though?  I can't think of one
case where I wouldn't know it.  Which only means that I can't think
of one.  Can you?

In any case, this idea struck me as incredibly useful, and I had
the existing source code/concepts lying around to handle most of
it, so I wrote it last night.  I call it ResAnomaly, and I'm just
about to post it to alt.sources.mac, comp.sources.mac, and
macgifts.

It doesn't have a user interface yet, but it's very easy to
configure using a resource editor and a compiler...

This is sample output:

/*
   Resource information for file Nyet 68k!

   This file was autogenerated by ResAnomaly.
   [e-mail] for more information.
*/

const short kResRamblin__ALRT_ID = 128;
const short kResError_2_ALRT_ID = 129;
const short kResAbout_ALRT_ID = 200;
const short kResRequired_Suite_aedt_ID = 128;

Source code/project file is included.

--
Chris Thomas, [e-mail]
"And the moral of this episode is: Gene Roddenberry's dead, so let's just suck."

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 27 Jun 1995 10:37:41 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Chris Thomas <[e-mail]> wrote:

>What's the point of listing the type, though?  I can't think of one
>case where I wouldn't know it.  Which only means that I can't think
>of one.  Can you?

Actually, yes. When I store settings in my preferences file I use
resources with various types which I choose more or less randomly
so it would be useful to have the program generate a constant for
the type. Well, at least optionally.



--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Gregory Jorgensen)
Date: Fri, 23 Jun 1995 14:29:29 -0800
Organization: Radix Consulting Inc.

In article <1995Jun23.090628.23402@hrbicf>, [e-mail] (Mark H.
Linton) wrote:

> > Does ResEdit or Resorcerer offer the option to generate a header
> > file (*.h) of resource IDs?
> >

Resorcerer has a built-in script language; it could probably be made to do
this for you.

Referring to resources by name works for me. Fewer than half of my
resources are gotten by ID. When I don't care about the ID or order I use
GetIndResource to just get them all. I have a nifty little function that
gets the ID of each resource of a specific type, then sorts the IDs (which
GetIndResource won't do).

> I don't think so but it sure would be a great idea...
>
> HELLO, IS ANYBODY LISTENING?
>
> I do most of my work in Rez format (I like to be able to print out
> and review my work--I guess everybody else just gets it right the
> first time =^). Actually this is one of the reasons I still use SC
> (I use CW also, but wish they had REAL Rez support). It is also
> very convinient because the Rez file listens to my
> ResourceDefinitions.h header for resource IDs, etc, while the
> strictly graphical stuff (that I create with ResEdit, Resourcerer
> is way to $$$, IMHO) is FIXED IN STONE, which makes it less than
> portable from project to project.

Resorcerer is only too expensive until you use it. Then you wonder how you
got along without it.

--
Gregory Jorgensen
radix consulting inc
[e-mail], [e-mail]

"I would consent to have a limb amputated to recover my spirits." -- Samuel Johnson

+++++++++++++++++++++++++++

>From [e-mail] (Robert H Guttman)
Date: Tue, 27 Jun 1995 23:07:15 -0700
Organization: Arizona State University

In article <3son1l$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

> In article <[e-mail]>,
> Chris Thomas <[e-mail]> wrote:
>
> >What's the point of listing the type, though?  I can't think of one
> >case where I wouldn't know it.  Which only means that I can't think
> >of one.  Can you?
>
> Actually, yes. When I store settings in my preferences file I use
> resources with various types which I choose more or less randomly
> so it would be useful to have the program generate a constant for
> the type. Well, at least optionally.
>
> --
> Francois Pottier

Chris, have you posted your "ResAnomaly" to alt.sources.mac or
comp.sources.mac yet?   Francois, have you worked on your version?
(BTW, nice home page.)  I'm looking forward to trying them out.

One comment: You two were discussing naming conventions for the
outputed constants.  In that Windows 3.1/Borland C++ Workbench
tool, the *name* of the ID was used as the constant's name.
While this may not be the universal solution (especially since
ResEdit ID names can be multiple words), perhaps it can be an
option.  I guess what I had envisioned was something like this:

   Let's say that I've defined the following resources:

      Resource    ID    Name
      --------    -----------------
        STR#      128   iAlerts
                  129   iMessages
        WIND      128   iDocWind

   I would expect as output, in some res.h file:

      /* STR# resources */
      #define  iAlerts        128
      #define  iMessages      129

      /* WIND resources */
      #define  iDocWind       128

As you know, the whole point is to complement the standard way
of defining resources (not to change it) via a tool that can
generate a resource ID header file.  This would replace the need
to duplicate resource information in our source code.  I believe
that resource information should be defined in one place, namely
the resource file.  Currently, this is not the standard practice.

Thanks.
- Rob ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Resorcerer)
Date: 30 Jun 1995 01:37:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

Question:

Although it doesn't happen very often, it is perfectly legal for a
resource file to have multiple resources with the same ID.  You have to
access the resources by unique resource name, rather than ID.

How would you propose to handle this situation (aside from punting, which
is not an unreasonable situation).

Doug McKenna
Mathemaesthetics, Inc.
Developers of Resorcerer

+++++++++++++++++++++++++++

>From [e-mail] (Robert H Guttman)
Date: Fri, 30 Jun 1995 11:30:00 -0700
Organization: Motorola GSTG

In article <[e-mail]>, [e-mail]
(Gregory Jorgensen) wrote:

> > > Does ResEdit or Resorcerer offer the option to generate a header
> > > file (*.h) of resource IDs?
>
> Resorcerer has a built-in script language; it could probably be made to do
> this for you.

I'm sure it could.  But Chris Thomas just created an excellent little
utility called ResAnonamly to do just this.  It's customizable, too:

    <ftp://mirrors.aol.com:/pub/info-mac/dev/res-anomaly-10.hqx>

Just drop your resource file onto ResAnonamly and save the newly generated
header file of resource IDs.  It's that easy.

- Rob Guttman
  email: [e-mail]
  phone: [phone], fax: [phone]
  Motorola GSTG, Scottsdale, AZ  (USA)
  Artificial Intelligence Applications

+++++++++++++++++++++++++++

>From [e-mail] (Robert H Guttman)
Date: Sat, 01 Jul 1995 13:56:57 -0700
Organization: Arizona State University

In article <3t02i1$[e-mail]>, [e-mail]
(Resorcerer) wrote:

> Question:
>
> Although it doesn't happen very often, it is perfectly legal for a
> resource file to have multiple resources with the same ID.  You have to
> access the resources by unique resource name, rather than ID.
>
> How would you propose to handle this situation (aside from punting, which
> is not an unreasonable situation).
>
> Doug McKenna
> Mathemaesthetics, Inc.
> Developers of Resorcerer

Like many types of software tools, certain conventions need to be followed
for their optimal use.  You can think of these as limitations of the tools
although oftentimes, they help improve the reliability or maintainability
of the code.

As for having multiple resources with the same ID, this shouldn't pose as
a problem for a tool such as ResAnomaly.  If we had two window resources
with the same ID, for example, a possible output of ResAnomaly could be:

   #define iMyDocumentWIND 128
   #define iMyDialogWIND 128

It should be noted that while having the same ID for same-type resources
may be permissible, it is discouraged.  The problem case, however, occurs
when two resources of the same type have the same name (regardless of
their IDs).  This practice is not necessarily discouraged and more likely
to occur than redundant IDs.

In this case, a tool like ResAnomaly could simply "punt", simply append
consecutive numbers to the existing name, or a number of other solutions.
However, this is where a certain programming convention could (optionally)
be enforced.  As a user of such a tool, I would prefer that, in this case,
ResAnomaly (or similar tool) warn me of the name conflict and abort the
generation of the resource header file.

I welcome the option of having a convention forced upon me if it could
potentially improve the reliability or maintainability of my code.  I
would even put this type of protection up there with local file locking
when using configuration management systems.  Such conventions, while
perhaps limiting us in some way, exist to help prevent us from shooting
ourselves in the foot.

   [For those of you not familiar with ResAnomaly, it is an excellent
   utility recently written by Chris Thomas for automatically generating
   a header file of resource IDs by simply drag and dromight be a time-saving thing to create the
> definitions once from a large resource file for which there are no
> definitions, but my experience as a developer has been that I'll typically
> add only a couple of resources (at most) at a time to a resource file, and
> adding my own symbolic constants to my initially empty "ResourceIDs.h"
> file takes only a few seconds.

Well, the _ResAnomaly_ (hey, I thought you were the Mathemaesthetics
Spelling Wizard) scheme is more flexible than it might be.

> I think a better solution would be for the resource editor to go to the
> effort of understanding one's header file, rather than the resource editor
> forcing you to understand its header file.  This is a much harder problem,
> but one which (the great god of development willing) the next version of
> Resorcerer will hopefully solve.  Once that's done, having the resource
> editor generate an initial file of symbolic definitions would be just
> frosting on the cake.

That _does_ sound interesting.  Run through the
header file, parsing macros, enums, and const declarations.  Then
apply to the resource file.  I see two problems:  how are you
going to determine the resource type?  Requiring a standard
format doesn't seem right.  Also, ResAnomaly, by default, writes the
string as const short kMyResource_DLOG_ID = 128;  What if the
user decides to use English?  kMyResourceDialogID = 128?  New
preferences for english to filetype translation?

--
Chris Thomas, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (George Stepanek)
Date: 4 Jul 1995 07:35:37 GMT
Organization: N/A

In article <ckt-0207951823240001@0.0.0.0>
[e-mail] (Chris Thomas) writes:

> What ResAnomaly will do is warn you of the conflict, give you the
> option of skipping the resource, stopping altogether, or writing it
> to the file anyway.  Memory reqs will increase, but we're using temp
> memory anyway.
>
> No promises as to time of completion, but might be this week.

Ahem, while you're about it, could I make another suggestion? I find
the listing of the resource IDs to be extremely useful, and the only
thing that would be more useful would be if it also listed MENU and
DITL items as well. Is this possible? Is this desirable?

George Stepanek         ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Resorcerer)
Date: 5 Jul 1995 14:43:44 -0400
Organization: America Online, Inc. (1-800-827-6364)

Chris -

>>(hey, I thought you were the Mathemaesthetics Spelling Wizard)

Mea culpa.

>>I see two problems:  how are you
going to determine the resource type?  Requiring a standard
format doesn't seem right.

One possibility is to use a #pragma to give special attributes to certain
definitions and enums that would be ignored by the C compiler.

Doug McKenna
Mathemaesthetics, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Robert H Guttman)
Date: Wed, 05 Jul 1995 15:08:48 -0700
Organization: Motorola GSTG

In article <3t9g92$[e-mail]>, [e-mail]
(Resorcerer) wrote:
>
> The only problem I have with the ResAnomoly scheme is that I always feel
> that algorithmically-generated symbolic names are always going to be less
> readable and less easier to use than the one's you create for yourself.  I
> can understand why it might be a time-saving thing to create the
> definitions once from a large resource file for which there are no
> definitions, but my experience as a developer has been that I'll typically
> add only a couple of resources (at most) at a time to a resource file, and
> adding my own symbolic constants to my initially empty "ResourceIDs.h"
> file takes only a few seconds.

In my experience, the problem is not when adding new resources but when
modifying existing resources.  When resource IDs change, all header files
and/or source code references must be manually updated.  The more changed
IDs, the more updating required, thus the more chance for run-time errors
(not compile-time errors).  Hopefully, these would be caught via testing.

> I think a better solution would be for the resource editor to go to the
> effort of understanding one's header file, rather than the resource editor
> forcing you to understand its header file.  This is a much harder problem,
> but one which (the great god of development willing) the next version of
> Resorcerer will hopefully solve.  Once that's done, having the resource
> editor generate an initial file of symbolic definitions would be just
> frosting on the cake.

This *is* a much harder problem.  If I understand you correctly, I would
be able to use Resorcerer to generate an initial header file, add anything
else I wanted to the file (i.e., comments, other constants, etc.), and
then have Resorcerer update the file with the latest resource IDs (and/or
names) without disrupting the extra info that I had added.  This would be
comparable to GUI builders that can effectively manipulate previous output
that had callbacks added (for example) or CASE tools that can read back in
previous source code output (for example) to continue design work.

This would be a highly welcome addition to Resorcerer.

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: 6 Jul 1995 14:15:00 GMT
Organization: The Pitt, Chemistry

In article <rguttman-0507951508500001@137.124.91.131>,
[e-mail] (Robert H Guttman) wrote:

>If I understand you correctly, I would
>be able to use Resorcerer to generate an initial header file, add anything
>else I wanted to the file (i.e., comments, other constants, etc.), and
>then have Resorcerer update the file with the latest resource IDs (and/or
>names) without disrupting the extra info that I had added.


    I think I would keep the Resorcerer generated header as a
      separate header file, and add my own constants with
      a different file.  That way less risk of the computer
      generated file choking on or mulching my own additions.


 ---------------------= Nicholas C. DeMello =--------------------

 Internet: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


---------------------------

>From [e-mail] (William Turner)
Subject: Components and A5
Date: 04 Jul 1995 07:19:24 GMT
Organization: Los Angeles Macintosh Group BBS


Is anyone making globally-registered components? I'm confused about this
business of SetComponentInstanceA5... do I set a value for this? Do I just
drop to assembly, move.l a5, d0, then pass the d0 value to
SetComponentInstanceA5? Does this have to come BEFORE
SetComponentInstanceStorage? (I've seen some production code where Set...A5
came AFTER Set...Storage.) And what about the PowerPC; I don't have the
microprocessor book for that chip...

Thanks in advance...

-- William Turner ([e-mail])


+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 4 Jul 1995 20:25:01 GMT
Organization: University of Michigan

William Turner, [e-mail] writes:
 > Is anyone making globally-registered components? I'm confused about this
 > business of SetComponentInstanceA5... do I set a value for this? Do I just
 > drop to assembly, move.l a5, d0, then pass the d0 value to
 > SetComponentInstanceA5? Does this have to come BEFORE
 > SetComponentInstanceStorage? (I've seen some production code where Set...A5
 > came AFTER Set...Storage.) And what about the PowerPC; I don't have the
 > microprocessor book for that chip...

One great use for SetComponentA5() would be if you have a background-only
application that offers plug-in services for other programs or inside other
A5-contexts. You can use SetA5() to do what you are looking for.

    long SetA5(long);  Sets A5 to a particular value, and returns the old
                       value to the caller.

Try this snippet from your components home context:


        long saveA5;

        SetA5(saveA5 = SetA5(0);
        SetComponentInstanceA5(saveA5);


Saving A5 does not depend on saving component storage, so calling in either
order should be fine. Also, since you don't need to worry about globals in
PowerPC code (because the CFM manages it for you), SetA5() doesn't need to
do anything -- in fact its #define'd to 0.

If you haven't checked NIM:More Toolbox, that is a great place to start. It
took me a few readings to feel comfortable with the workings of the Component
Manager. You might even check out the snippets or Q+A documents that Apple
has online:

    ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/
       /Sample_Code/Snippets/Snippets_-_Toolbox.sit.hqx

    ftp://sam.austin.apple.com/Apple.Support.Area/Developer_Services/
       //Technical_Documentation/Mac_Tech_Notes/TB-Toolbox/TN-Toolbox.sit.hqx


I even have a (poorly written) shell component that I keep around. It was
my first attempt, and it doesn't maintain global information across its
instances... but it does seem to work.

Matt

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 06 Jul 1995 10:46:59 +0800
Organization: Department of Computer Science, University of Western Australia

In article <3tc82t$[e-mail]>, Matt Slot
<[e-mail]> wrote:

>I even have a (poorly written) shell component that I keep around. It was
>my first attempt, and it doesn't maintain global information across its
>instances... but it does seem to work.

Talking about components, Internet Config has lots of, shall we say...
fascinating, component source code, that deals with creating a component
and creating override components.  Source code is available as part of the
IC programmer's kit on...

  <ftp://redback.cs.uwa.edu.au/Others/Quinn/Config/>
  <ftp://ftp.share.com/internet-configuration/>

Share and Enjoy.
--
Quinn "The Eskimo!"      "Space army! I'd death ray my grandmother
                          for a space army about now."

---------------------------

>From [e-mail] (Bill A. Oyler)
Subject: Converting a string with numbers to an integer?
Date: Wed, 05 Jul 1995 23:18:50 -0500
Organization: The Dark Knight's Table BBS

Hello,

I have a (hopefully) simple question regarding THINK Pascal.  In my
program, I use the toolbox call GetIText to get the contents of a text
edit field into a string/str255.  But all I want to get from that text
edit box is the numbers it contains.  So if a user enters "4 Sale" in the
edit field, all I want is the "4".  I also need to make sure a number
greater than 0 is entered.

Does anyone know how I can easily accomplish this?

=====================================================
Bill A. Oyler               People usually get what's
Minnetonka, MN, USA         coming to them ... unless
[e-mail]            it's been mailed.
=====================================================

+++++++++++++++++++++++++++

>From Helge Ziegler <[e-mail]>
Date: 6 Jul 1995 16:39:46 GMT
Organization: University of Calgary Chemistry Departement

[e-mail] (Bill A. Oyler) wrote:
>Hello,
>
>I have a (hopefully) simple question regarding THINK Pascal.  In my
>program, I use the toolbox call GetIText to get the contents of a text
>edit field into a string/str255.  But all I want to get from that text
>edit box is the numbers it contains.  So if a user enters "4 Sale" in the
>edit field, all I want is the "4".  I also need to make sure a number
>greater than 0 is entered.
>
>Does anyone know how I can easily accomplish this?

Hi,
        There are two routines that might be usefull for you, NumToString and
StringToNum. They are both listed on pp. 489-490 in IM Vol. 1. (I don't
know where they would be listed in the new IM books).

PROCEDURE NumToString( theNum: LONGINT; VAR theString: Str255);
PROCEDURE StringToNum( theString: Str255,; VAR theNum: LONGINT);




+++++++++++++++++++++++++++

>From [e-mail] (Bill A. Oyler)
Date: Thu, 06 Jul 1995 22:46:33 -0500
Organization: The Dark Knight's Table BBS

In article <3th3ki$[e-mail]>, Helge Ziegler
<[e-mail]> wrote:

>         There are two routines that might be usefull for you, NumToString and
> StringToNum. They are both listed on pp. 489-490 in IM Vol. 1. (I don't
> know where they would be listed in the new IM books).

Thanks, that's JUST what I needed to know!

=====================================================
Bill A. Oyler               People usually get what's
Minnetonka, MN, USA         coming to them ... unless
[e-mail]            it's been mailed.
=====================================================

+++++++++++++++++++++++++++

>From [e-mail] (Jim Nash)
Date: 7 Jul 1995 20:51:53 GMT
Organization: SRS

[e-mail] (Bill A. Oyler) wrote:
> >Hello,
> >
> >I have a (hopefully) simple question regarding THINK Pascal.  In my
> >program, I use the toolbox call GetIText to get the contents of a text
> >edit field into a string/str255.  But all I want to get from that text
> >edit box is the numbers it contains.  So if a user enters "4 Sale" in the
> >edit field, all I want is the "4".  I also need to make sure a number
> >greater than 0 is entered.
> >
> >Does anyone know how I can easily accomplish this?

I am putting together a toolbox extender that has what you want.  So that
you do not have to buy the whole thing, here is the part that extracts the
"word" "4".  Then use StringToNum.  Another routine in my toolbox extender
library calls GetNextWord and includes a test that the number is really a
number:

 procedure RemoveLeadingSpace (var stg: Str255);
  var
   i, len: integer;
 begin
  len := length(stg);
  i := 1;
  if len > 0 then
   begin
    while (stg[i] in [' ', TAB]) and (i < len) do
     i := i + 1;
    if (stg[i] in [' ', TAB]) then
     i := i + 1;
   end;
  if i > len then
   stg := ''
  else if i > 1 then
   stg := copy(stg, i, 999);
 end;


 procedure RemoveTrailingCR (var stg: Str255);
  var
   len: integer;
 begin
  len := length(stg);
  if stg[len] = CR then
   stg := copy(stg, 1, len - 1);
 end;


 procedure GetNextWord (var stg, wrd: Str255);
  var
   len, len1: integer;
 begin
  RemoveLeadingSpace(stg);
  RemoveTrailingCR(stg);
  len := pos(' ', stg);
  len1 := pos(TAB, stg);
  if (len1 > 0) and ((len1 < len) or (len = 0)) then
   len := len1;   {Use either tab or space, whichever encountered first}
  if len = 0 then
   len := length(stg)
  else
   len := len - 1;
  wrd := copy(stg, 1, len);
  stg := copy(stg, len + 2, 99);
  if len > 0 then
   while (pos(' ', stg) = 1) do
    stg := copy(stg, 2, 99);
 end;

____________________________________________________________________
James W. Nash, Synergistic Research Systems
4409 Mahan Court, Silver Spring, MD 20906, USA
[phone], fax: [phone]
____________________________________________________________________

+++++++++++++++++++++++++++

>From z044304 (James Derrick)
Date: Sun, 09 Jul 1995 12:31:18 +0800
Organization: The Chinese University of Hong Kong

In article <[e-mail]>,
[e-mail] (Bill A. Oyler) wrote:

> Hello,
>
> I have a (hopefully) simple question regarding THINK Pascal.  In my
> program, I use the toolbox call GetIText to get the contents of a text
> edit field into a string/str255.  But all I want to get from that text
> edit box is the numbers it contains.  So if a user enters "4 Sale" in the
> edit field, all I want is the "4".  I also need to make sure a number
> greater than 0 is entered.
>
> Does anyone know how I can easily accomplish this?

Be careful of StringToNum.  It will not extract letters properly, and you
will get garbage numbers.

--
James Derrick

---------------------------

>From [e-mail] (Eric Clements)
Subject: Does anyone have code to get Ethernet Address?
Date: Sat, 01 Jul 1995 10:52:56 -0500
Organization: BDM International, Inc.

I have to write a small install program that tracks the hardware ethernet
address as the key to where it has been installed.  Does anyone have any
code, or the function calls I need to look up a Ethernet Hardware
address.  Please Help.  Very important.

Thank you in advance.

- ------------------------------------------------------------------
Eric R. Clements <[e-mail]>
Corporate Information Systems, Network Engineer
BDM International, Inc.

This is my opinion, not necessarily the opinion of my Employer.

+++++++++++++++++++++++++++

>From [e-mail] (Andrew J. Willmott)
Date: Sun, 02 Jul 1995 13:10:47 -0400
Organization: CMU SCS

In article <[e-mail]>,
[e-mail] (Eric Clements) wrote:

> I have to write a small install program that tracks the hardware ethernet
> address as the key to where it has been installed.  Does anyone have any
> code, or the function calls I need to look up a Ethernet Hardware
> address.  Please Help.  Very important.
>
> Thank you in advance.
>

This is from an old hack of mine to do that kind of thing. I think the
original code was from Rich Kubota of DTS. It runs under Metrowerks';
you'll have to change CallLAPMgr to the Think C Asm style to get it to run
under that compiler.

- -
File: GetEtherAddress.c

#include <Types.h>
#include <ENET.h>
#include <Devices.h>
#include <AppleTalk.h>

#define LGetATalkInfo   0x09    /* Get AppleTalk info */
#define kSPConfig       0x1FB   /* low nibble of global byte indicates
whether AppleTalk active */

#define ETalkPh1        2       /* Ethernet Phase 1 ADEV resource ID */
#define ETalkPh2        10      /* Ethernet Phase 2 ADEV resource ID */

#include "GetEtherAddr.h"

long        CallLAPMgr(short selector);

int FindEthernetAddress(char *eNetAddress)
{
    EParamBlock pb;
    OSErr       err;
    long        result;
    char        adevType;
    char        slot;
    short       buffer[39];     // 78/2
    Ptr         spConfigPtr;

    result = CallLAPMgr(LGetATalkInfo);     /* get current connection setting */
    adevType = result & 0x000000FF;         /* atlk resource id is return
in LSB */
    slot = result >> 24;                    /* card slot returned in MSB */

    spConfigPtr = (Ptr)kSPConfig;
    if ((*spConfigPtr & 0x0F) != 1)  /* Check whether AppleTalk is enabled */
        return(kNoAppleTalkErr);

    if ((adevType != ETalkPh1) && (adevType != ETalkPh2))
        return(kNoEthernetErr);

    /* now we know that AppleTalk is active and that EtherTalk is already
open */

    if ((err = OpenDriver("\p.ENET", &pb.EParms1.ioRefNum)) == noErr)
    {
        pb.EParms1.ePointer = (char *) buffer;
        pb.EParms1.eBuffSize = sizeof(buffer);
        err = EGetInfo(&pb, false);

        BlockMove(buffer, eNetAddress, 6);

        return(kNoErr);
    }
    else
        return(kCantOpenDriverErr);
}

asm long CallLAPMgr(short selector)
{
#define LAPMgrPtr   0xB18
#define LAPMgrCall  2

        LINK        A6,#0           // set up stack frame
        MOVE.W      8(A6),D0        // move selector parameter into D0
        MOVE.L      A2,-(A7)        // store A2 on stack
        MOVEA.L     LAPMgrPtr,A2    // Set A2 to address of LAP Mgr.
        JSR         LAPMgrCall(A2)  // Call LAP Manager
        MOVE.L      D1,D0           // Place result onto stack
        MOVE.L      (A7)+,A2        // Restore A2
        UNLK        A6              // restore stack frame
        RTS
}

- -

Cheers,

Andrew

- -------------------------------------------------------------------
                   In the caves all cats are grey.
- - mailto:[e-mail] ----- http://www.cs.cmu.edu/~ajw ---

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 03 Jul 1995 09:53:38 +0800
Organization: Department of Computer Science, University of Western Australia

In article <[e-mail]>,
[e-mail] (Eric Clements) wrote:

>I have to write a small install program that tracks the hardware ethernet
>address as the key to where it has been installed.  Does anyone have any
>code, or the function calls I need to look up a Ethernet Hardware
>address.

I don't have my source archive handy at the moment but this is all
documented in NIM:Networking.  Just read the docs, it's about 20 lines of
code.

Share and Enjoy.
--
Quinn "The Eskimo!"      "Space army! I'd death ray my grandmother
                          for a space army about now."

---------------------------

>From [e-mail] (<===Conner===>)
Subject: FutureBasic Mailing List?
Date: 7 Jul 1995 17:47:47 GMT
Organization: Wolfe Internet Access, L.L.C.

Does anyone know or have the address for a FutureBasic Mailing List? I
have several problems that I need to discuss with avid FB programmers.

Thanks

Conner


+++++++++++++++++++++++++++

>From [e-mail] (Mel Patrick)
Date: Fri, 07 Jul 1995 12:14:23 -0700
Organization: Wabbit Wangler

In article <3tjs03$[e-mail]>, [e-mail] (<===Conner===>)
wrote:

>Does anyone know or have the address for a FutureBasic Mailing List? I
>have several problems that I need to discuss with avid FB programmers.
>
Sorry to report the list server for FutureBasic is more down than up
lately. Here is the info if and when it gets resurrected...

To join the Futurebasic list list, please use the following.

        mail [e-mail]
        Subject: anything can go here..

        subscribe futurebasic YourFirstName YourLastName


Please make sure you use your real name and not the example above.

To unsubscribe, again...

        mail [e-mail]
        Subject: anything can go here..

        unsubscribe futurebasic


To post comments or queries about FB, to the list:
[e-mail]

Anonymous ftp facilities are available at:
        ftp://ftp.geko.com.au//pub/future-basic (only if you're in AU!)
There is another ftp site at:
        ftp://tirpitz.ibg.uit.no
also try:
        ftp://ingrimayne.saint.joe.edu

If you have any questions, or problems with the mail-list, please e-mail me.

Enjoy.

Kind Regards,

William Bullock
[e-mail]

___________________
This is all the info I have, but when the list is running, there are about
200 of us on it.

--
Mel Patrick
[e-mail]

---------------------------

>From [e-mail] (John C. Daub)
Subject: How do you write 'TMPL' resources?
Date: 23 Jun 1995 17:22:55 GMT
Organization: Texas A&M University


Hola y'all :)

How do you write 'TMPL' (template) resources?  I've tried looking through
a lot of examples and also looking around the net for something that
might document or give an example of how to write them, but so far
i've found nothing that really helps.

anyone know of where i could find documentation, tutorials, etc?

books, URL's, anything would be greately appreciated :)

Please email me any replies (or if you can, both email the reply to me
and post it too cause i'm sure there are probably other people out there
that might find this information useful) :)

Thanx in advance!

--
* John C. Daub (Hsoi) * Grad Student,TA * Speech Communication * Texas A&M *
*    mailto: [e-mail]             http://tam2000.tamu.edu/~jcd7106/   *
* "Don't waste your time on me, I got my own direction.  Watch me close,   *
*  just wait and see, I'm looking for perfection"        - Ted Nugent      *

+++++++++++++++++++++++++++

>From [e-mail] (Greg Manning)
Date: Fri, 23 Jun 1995 14:37:32 -0700
Organization: GDT Softworks Inc.

In article <[e-mail]>, [e-mail] wrote:

> How do you write 'TMPL' (template) resources?

John,

TMPL's are described in the "ResEdit Reference" book, which you get when you
buy ResEdit.  If you buy ResEdit on MPW Pro you get "ResEdit Reference" in
DocViewer format on the CD.

Resourceror add some extensions to TMPLs which are, naturally, described in
the Resourceror manual.

Greg

--
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jacob Weber)
Date: Sat, 24 Jun 1995 22:17:33 -0700
Organization: Primenet

In article <[e-mail]>, [e-mail] wrote:

>Hola y'all :)
>
>How do you write 'TMPL' (template) resources?  I've tried looking through
>a lot of examples and also looking around the net for something that
>might document or give an example of how to write them, but so far
>i've found nothing that really helps.

A good book for learning this kind of thing is ResEdit Complete (published
by Addison-Wesley). It gives instructions for creating TMPLs and various
other things, including writing your own editors.

Basically, a TMPL is just a list of fields, each with a label and a type.
Labels can be anything you want. Types can include DBYT (byte), DWRD
(word), P0FF (Pascal string), and several others. The name of the TMPL
resource must be the same as the resource type it will be used for.

For example, if you have a resource with two words followed by a string,
your TMPL could look like this:

  1) ***
  Label: First Word
  Type:  DWRD

  2) ***
  Label: Second Word
  Type:  DWRD

  3) ***
  Label: String
  Type:  P0FF

Then, when you edit your resource, it will look like this:

  First Word   [....]
  Second Word  [....]
  String       [.................]

- --------------------------------------------------------
Produced, Arranged, Composed, and Performed by Jacob Weber
[e-mail]                        CIS: 72303,3540

+++++++++++++++++++++++++++

>From [e-mail] (Patrick C Hew)
Date: 25 Jun 1995 08:04:14 GMT
Organization: The University of Western Australia

This material is summarized in obiwan, which can
be found in the info-mac archive (info-mac/dev).

Version 5 requires System 7.1, though I think
Version 4 can run under System 6 (it certainly
runs under 7.0).

The keyword for templates is "template" (I think
from memory... it may be TMPL). Also note that
the THINK Class Library defines some TMPLs for use
with the Library, and you may want to look at these
as an example (Don't copy them exactly, of course :)

Hope this helps,

Patrick

Patrick Hew
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Shay Telfer)
Date: Wed, 05 Jul 1995 10:58:19 +0800
Organization: Black Sun Systems

In article <3sj59u$[e-mail]>, [e-mail] (Patrick
C Hew) wrote:

> This material is summarized in obiwan, which can
> be found in the info-mac archive (info-mac/dev).
>
> Version 5 requires System 7.1, though I think
> Version 4 can run under System 6 (it certainly
> runs under 7.0).
>
> The keyword for templates is "template" (I think
> from memory... it may be TMPL).

ResEditTemplates

Have fun,
Shay

--
=========================== Shay  Telfer ============================
 Perth, Western Australia.  Technomancer "He's probably one of those
 Opinions for hire.             [POQ]      people who thinks that
 [e-mail]                         Elvis is dead" Fox Mulder

---------------------------

>From [e-mail] (Roger Brown)
Subject: How much of a sound has played so far?
Date: 27 Jun 1995 14:11:15 GMT
Organization: Dartmouth College, Hanover, NH

I want to play a sound from a file and know how much has played at any
one time. I have a controlling device and want to be able to "rewind"
and "fast forward" through the sound. To do that, It would help to know
what the current position is.

A call to SndChannelStatus pretends to do what I want, giving me access
to a SCStatus record having a scCurrentTime field, but it is rarely
close to correct. The Inside Mac Sound volume admits that this value is
not updated very often and is not to be relied upon.

So how can I tell how much sound has played, short of tracking the time
independently?

Any suggests are appreciated.

- ------------------------------------------------------------------
Roger Brown                                [e-mail]
Software Development
Kiewit Computation Center, Dartmouth College, Hanover, NH, USA

+++++++++++++++++++++++++++

>From Maf Vosburgh <[e-mail]>
Date: 27 Jun 1995 17:45:00 GMT
Organization: MMC

In article <3sp3i4$[e-mail]> Roger Brown,
[e-mail] writes:
>
>So how can I tell how much sound has played, short of tracking the time
>independently?


Jim Reekes told me at the WWDC (namedrop alert) that the recommended
way to play AIFF files from disk is now to use QuickTime. Version 2.0
of QT will let you open and play an AIFF file as if it was a movie.
That gives you much finer time resolution.

- -------------------------------------------------------------
Real QT experts just use MoviePlayer, Dumpster & ConvertToMovie.
Real C programmers use [0]-> (and it's called "sprong").

+++++++++++++++++++++++++++

>From [e-mail] (tinyjohn)
Date: 27 Jun 1995 16:22:29 GMT
Organization: complex

In article <3sp3i4$[e-mail]>
[e-mail] (Roger Brown) writes:

> A call to SndChannelStatus pretends to do what I want, giving me access
> to a SCStatus record having a scCurrentTime field, but it is rarely
> close to correct. The Inside Mac Sound volume admits that this value is
> not updated very often and is not to be relied upon.

When I was writing BigSound I noticed that the accuracy of the value
returned by SndChannelStatus increases when you use a smaller buffer
with SndStartFilePlay.  However, using a smaller buffer seemed to
break up the sound on slower hardware.

Just an observation, I dunno if it's true for all versions of the sound
manager or on all makes and models.

-john

- -------------------------------------------------------------------
-     John Montbriand             P.O. Box. 1133                    -
-     [e-mail]      Saskatoon Saskatchewan Canada     -
-     [phone]              S7K 3N2                           -
- -------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Tue, 27 Jun 1995 19:43:01 -0500
Organization: Borg


In article <3sp3i4$[e-mail]>,
[e-mail] (Roger Brown) wrote:

> So how can I tell how much sound has played, short of tracking the time
> independently?

You track the time independently.

Or you use a professional sound system, like Digidesigns stuff, which come
with their own interface which is more capable (and more cumbersome) than
the Sound Manager. They still work with the Sound Manager, though.

Cheers,

                                / h+


--
 Jon Wdtte, 11266 Taylor Draper Ln #2517, Austin
 Work: [e-mail]  Play: [e-mail]          News != Work


+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Thu, 06 Jul 1995 12:10:36 -0700
Organization: Apple Computer, Inc.

In article <3spg2s$[e-mail]>, Maf Vosburgh <[e-mail]> wrote:

> In article <3sp3i4$[e-mail]> Roger Brown,
> [e-mail] writes:
> >
> >So how can I tell how much sound has played, short of tracking the time
> >independently?
>
>
> Jim Reekes told me at the WWDC (namedrop alert) that the recommended
> way to play AIFF files from disk is now to use QuickTime. Version 2.0
> of QT will let you open and play an AIFF file as if it was a movie.
> That gives you much finer time resolution.

Yes, the best way to play sound files is with QuickTime. This can play
AIFF, .au, .wav, and of course movie files. The SCStatus struct is only
update when the buffer is filled. This means that a large buffer is update
less often. The smallest buffer allowed is about 20k, and this means for a
22kHz sound you'll get at best 1 second of resolution in timing.

--
Jim Reekes, Polterzeitgeist |       QuickTime Products R&D
                            |        Sound Manager Expert
Apple Computer, Inc.        | "All opinions expressed are mine, and
2 Infinite Loop  MS 302-3KS |  do not necessarily represent those
Cupertino, CA 95014         |  of my employer, Apple Computer Inc."

+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Mon, 10 Jul 1995 16:44:19 -0700
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Jon
W{tte) wrote:

> In article <3sp3i4$[e-mail]>,
> [e-mail] (Roger Brown) wrote:
>
> > So how can I tell how much sound has played, short of tracking the time
> > independently?
>
> You track the time independently.
>
> Or you use a professional sound system, like Digidesigns stuff, which come
> with their own interface which is more capable (and more cumbersome) than
> the Sound Manager. They still work with the Sound Manager, though.

Also, just use QuickTime to play the AIFF, .wav, or .au files and ask
QuickTime for the time.

--
Jim Reekes, Polterzeitgeist |       QuickTime Products R&D
                            |        Sound Manager Expert
Apple Computer, Inc.        | "All opinions expressed are mine, and
2 Infinite Loop  MS 302-3KS |  do not necessarily represent those
Cupertino, CA 95014         |  of my employer, Apple Computer Inc."

---------------------------

>From [e-mail] (Michael K. Neylon)
Subject: How to "rubber bands"?
Date: Thu, 06 Jul 1995 11:41:49 GMT
Organization: University of Michigan

Does there exist any Toolbox calls to draw the animated dash line that
appears when one does a "rubber band" selection (ie dragging a
rectangle on the Finder to select multiple items).  I only need to do
this for a rectangular region, although I suspect that this does not
matter.

TIA...

  Michael K. Neylon, Graduate Student           | "It was a dark and stormy
  Dept. of ChE, Univ. of Michigan               |   night...I had just
  [e-mail]                       |   taken a creative
  http://www.engin.umich.edu/~mneylon           |   writing course..." MST3K


+++++++++++++++++++++++++++

>From [e-mail] (Katy Agnor)
Date: Thu, 6 Jul 1995 13:53:02 GMT
Organization: The ForeFront Group

In article <3tgi63$[e-mail]>, [e-mail]
(Michael K. Neylon) wrote:

> Does there exist any Toolbox calls to draw the animated dash line that
> appears when one does a "rubber band" selection (ie dragging a
> rectangle on the Finder to select multiple items).  I only need to do
> this for a rectangular region, although I suspect that this does not
> matter.
>
> TIA...
>
>   Michael K. Neylon, Graduate Student           | "It was a dark and stormy
>   Dept. of ChE, Univ. of Michigan               |   night...I had just
>   [e-mail]                       |   taken a creative
>   http://www.engin.umich.edu/~mneylon           |   writing course..." MST3K

There is no one-liner in the Toolbox to do this, but here's some code that
does it just fine.  It even handles dragging the mouse in any direction
(ooooh - ahh).  Anyway, its trivial code... enjoy!

Katy

Rect RubberBandIt(Point anchorPt)
{
   Point curMousePt;
   Rect  rubberRect;

   curMousePt.h = 0;
   curMousePt.v = 0;

   PenMode(srcXor);                       /* Set pen mode to exclusive or.*/
   PenPat(&qd.gray);

   GetMouse(&curMousePt);                    /* Get current mouse pos.     */

   rubberRect.top = anchorPt.v;              /* Draw initial rectangle.    */
   rubberRect.left = anchorPt.h;
   rubberRect.bottom = curMousePt.v;
   rubberRect.right = curMousePt.h;
   DrawStuff(&rubberRect);

   while (Button())
   {
      GetMouse(&curMousePt);                 /* Get current mouse pos

      if (curMousePt.h != rubberRect.right ||      /* If mouse
moved
         curMousePt.v != rubberRect.bottom)
      {
         DrawStuff(&rubberRect);             /* Erase old
         rubberRect.bottom = curMousePt.v;
         rubberRect.right = curMousePt.h;
         DrawStuff(&rubberRect);             /* and draw new.           */
      }
   }

   DrawStuff(&rubberRect);                   // Erase old at end.       */
   CheckRect(&rubberRect);

   PenMode(srcCopy);
   PenPat(&qd.black);

   return(rubberRect);
}

void DrawStuff(rubberRect)
Rect  *rubberRect;
{
   Rect  curRect;

   curRect = *rubberRect;
   FrameRect(CheckRect(&curRect));
}


Rect *CheckRect(theRect)
Rect  *theRect;
{
   short temp;

   if (theRect->top > theRect->bottom)    /* Need to reverse top and bottom? */
   {
      temp = theRect->top;
      theRect->top = theRect->bottom;
      theRect->bottom = temp;
   }

   if (theRect->left > theRect->right)    /* Need to reverse left and right? */
   {
      temp = theRect->left;
      theRect->left = theRect->right;
      theRect->right = temp;
   }

   return theRect;                     /* This makes nested calls easier.  */
}

/---------------------------------------------------------/
Katy Agnor                     e-mail: [e-mail]
The ForeFront Group, Inc.      www:    http://www.ffg.com/
/---------------------------------------------------------/

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: Sun, 09 Jul 1995 16:49:37 -0800
Organization: Altura Software, Inc.

> There is no one-liner in the Toolbox to do this, but here's some code that
> does it just fine.  It even handles dragging the mouse in any direction
> (ooooh - ahh).  Anyway, its trivial code... enjoy!
[code snipped]

However, if you want your rubber band selection rects to look like the
Finder, you'll have to do some more work.  The previously posted code
works well for most situations; however, it causes some annoying flashing
of areas that don't change as you move the mouse.  If you look at the
Finder (use Macsbug's SS 0), you'll notice it only redraws areas that need
to be redrawn.

If there's demand, I'll gladly post some code that does a Finder style
rubber band selection.

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Who is John Galt?

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: 11 Jul 1995 23:14:12 GMT
Organization: Altura Software, Inc.

> > If there's demand, I'll gladly post some code that does a Finder style
> > rubber band selection.
> >
>
> Post it! Post it! (or atleast e-mail me a copy :-) )
>

It's posted to AOL, alt.sources.mac, and InfoMac.  It's called Finder
Marquee Rects or something like that.

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Who is John Galt?

---------------------------

>From [e-mail] (Rmeadows)
Subject: How to use TSM floating windows?
Date: 7 Jul 1995 10:57:44 -0400
Organization: America Online, Inc. (1-800-827-6364)

I'm trying to use the Text Services Manager (TSM) to use floating windows
(as described in IM:Text 7-79).  My application has the TSM and HLE bits
set, and I call InitTSMAwareApplication().  The window comes up in the
floating layer, but that's the end of the expected "normal" behavior.  I
have to do a HiliteWindow() to get the drag region drawn correctly
(SelectWindow() doesn't do it);  I get no update events at all (or any
other events for that matter) destined for the floating window.

I'm using WaitNextEvent() in my event loop, and use FindServiceWindow() to
catch mouseDown events in the floater (and it works) but it's kind of hard
to tell where to click when the window never gets drawn ('cause no update
events ever got there).  (I'm running 7.5.1 on a PPC 6100.)

I want to use this floater as a tool palette, not as a text input method;
so I pass "kCurrentProcess" as the "ts" parameter to NewServiceWindow() as
documented in IM.

Is there something that I'm missing here?  Is there something missing in
the IM documentation?

PLEASE PLEASE cc: a copy of your reply to "[e-mail]", as I
don't have a news feed, and have to check news via AOL.  THANKS!

Thanks in advance!
Randall Meadows
FGM, Inc.
[e-mail]

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 8 Jul 1995 05:54:22 GMT
Organization: University of Michigan

Rmeadows, [e-mail] writes:
 > I'm trying to use the Text Services Manager (TSM) to use floating windows
 > (as described in IM:Text 7-79).  My application has the TSM and HLE bits
 > set, and I call InitTSMAwareApplication().  The window comes up in the
 > floating layer, but that's the end of the expected "normal" behavior.  I
 > have to do a HiliteWindow() to get the drag region drawn correctly
 > (SelectWindow() doesn't do it);  I get no update events at all (or any
 > other events for that matter) destined for the floating window.
 > ...
 > Is there something that I'm missing here?  Is there something missing in
 > the IM documentation?

The IM documentation neglects to tell you how to get events, such as
clicks, keydowns, and updates for the TSM window. This is the *perfect*
opportunity for me to point out my "Appe Windows" source... a demo program
that creates and manages a TSM Floater.

To get the source, you can FTP it from Mac-Archives or Sumex mirrors...
or send me Email at [e-mail]

Matt

+++++++++++++++++++++++++++

>From [e-mail] (Dirk Dierckx)
Date: Sat, 08 Jul 1995 17:02:35 +0200
Organization: H20 Systems

In article <3tji18$[e-mail]>,
[e-mail] (Rmeadows) wrote:

>I'm using WaitNextEvent() in my event loop, and use FindServiceWindow() to
>catch mouseDown events in the floater (and it works) but it's kind of hard
>to tell where to click when the window never gets drawn ('cause no update
>events ever got there).  (I'm running 7.5.1 on a PPC 6100.)

You don't get update events for TSM windows.  The easiest way to check if a
floater needs an update is to check its updateRgn everytime you go through
your eventloop.





+++++++++++++++++++++++++++

>From [e-mail] (Rmeadows)
Date: 10 Jul 1995 10:02:33 -0400
Organization: America Online, Inc. (1-800-827-6364)

>You don't get update events for TSM windows.  The easiest way to check
>if a floater needs an update is to check its updateRgn everytime you go
>through your eventloop.

Is this documented anywhere (like in IM, or a tech note)?  Perhaps there's
more "tricks" I need to find out about this?

+++++++++++++++++++++++++++

>From [e-mail] (Dirk Dierckx)
Date: Tue, 11 Jul 1995 18:49:41 +0200
Organization: H20 Systems

In article <3trbtp$[e-mail]>,
[e-mail] (Rmeadows) wrote:

>>You don't get update events for TSM windows.  The easiest way to check
>>if a floater needs an update is to check its updateRgn everytime you go
>>through your eventloop.
>
>Is this documented anywhere (like in IM, or a tech note)?  Perhaps there's
>more "tricks" I need to find out about this?

I don't know if it's documented by Apple but it's fully explained in an
application named "AppeWin" or something like that.  As Matt Slot has
pointed out in his reply.  You can find it on Info-Mac somewhere in the
"dev" directory.  You'll also need the TSMFix INIT that comes with AppeWin
because there is a bug in the TSM that sometimes bypasses the jGNEFilters
when there is an event.  Resulting in lost clicks/keys.




---------------------------

>From dwilliss@tnt (Dave Williss)
Subject: Standalone Code Resources
Date: 10 Jul 1995 14:14:49 GMT
Organization: MicroImages, Inc.

I'm having a problem creating a standalone code resource to be used
as part of an install script (Using the Install SDK).

My problem is global data.  I can't seem to figure out how to set
it up.  There is some confusion as to whether I should be trying to
set A4 or setup an "A5 World".

I found reference to a Technote #256 that should tell about setting
up an A5 world, but on the Developer CD I have, the technotes are
not numbered that way.

I have followed what instructions I have found for setting up an A5
world, but now when I link (MPW linker), I get an error that says

        "Data to Code reference not supported (No Jump Table)"

or something like that.  Any idea what this means and how to solve it?
I've tracked it down to trying to preinitialize a global structure
with pointers to functions.  I tried temporarly not initializing the
structure and the link error just moved from my module to Runtime.o.

I assume there is just something I have to call when setting up my
A5 world which will resolve these things, but I don't know what.

--
David C. Williss                            #include <standard.disclaimer>
Software Engineer -- MicroImages, Inc.          [e-mail]
WWW: http://tnt.microimages.com/~dwilliss       [e-mail]
-- PGP Public Key available via finger from: [e-mail] --

+++++++++++++++++++++++++++

>From [e-mail] (PandH Phot)
Date: 10 Jul 1995 17:33:39 -0400
Organization: America Online, Inc. (1-800-827-6364)

Assuming you're using TC or CW, both provide macros for setting up and
breaking down *A4*, which will stand in for A5 in your Code Resource.
Basically, you just bracket any routine which acts as an entry point in
the code with the following (assuming CW is your environment):

At the start of the routine
long oldA4;
oldA4 = SetCurrentA4();

At the end of the routine
(void)SetA4(oldA4);

These are functionally equivalent to the Toolbox's A5 routines of the same
name, but act on A4 instead.

Happy coding!
Paul

---------------------------

>From [e-mail] (andrew meggs)
Subject: Which sndCommands are safe at interrupt time?
Date: Sat, 24 Jun 1995 20:54:13 GMT
Organization: University of Virginia


My life would be much happier if I could call SndDoCommand from
a Sound callback to tell a sound channel what to do next. The problem
is, IM-Sound offers the incredibly useless advice that "MOST of
the available sound commands do not cause SndDoCommand to move
memory and can therefore be issued at interrupt time."

I have a deep suspicion that bufferCmd might not fall under the
category of "most", since they talk about using soundCmd before
interrupt time to preconfigure the channel. Can anyone confirm or
deny this?

I also want to use waitCmd and callbackCmd, but I'm less concerned
about those than I am about bufferCmd.

--
andrew meggs
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (rodney jacks/vlk9)
Date: Mon, 26 Jun 1995 15:43:42 GMT
Organization: Motorola Inc., Austin, Texas

In article <[e-mail]>,
andrew meggs <[e-mail]> wrote:
>
>My life would be much happier if I could call SndDoCommand from
>a Sound callback to tell a sound channel what to do next. The problem
>is, IM-Sound offers the incredibly useless advice that "MOST of
>the available sound commands do not cause SndDoCommand to move
>memory and can therefore be issued at interrupt time."
>
>I have a deep suspicion that bufferCmd might not fall under the
>category of "most", since they talk about using soundCmd before
>interrupt time to preconfigure the channel. Can anyone confirm or
>deny this?
>
>I also want to use waitCmd and callbackCmd, but I'm less concerned
>about those than I am about bufferCmd.

My game, Jewelbox issues bufferCmds during a sound callback proc.
It's been out now for 3+ years and no one has ever reported a
problem with the game playing background music.  It even works
on the latest PowerMac's and Mac Application Environment (MAE).

Cheers,
Rodney
--
Rodney ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 26 Jun 1995 19:01:18 -0500
Organization: Random


In article <[e-mail]>,
[e-mail] (andrew meggs) wrote:

> I have a deep suspicion that bufferCmd might not fall under the
> category of "most", since they talk about using soundCmd before
> interrupt time to preconfigure the channel. Can anyone confirm or
> deny this?

A bufferCmd to play a buffer in a channel whose callback you're servicing
is always guaranteed to work. In fact; that's how QuickTime does it. I have
this directly from Jim Reeks, who wrote the Sound Manager, and he should
know :-)

Cheers,

                                / h+


--
 Jon Wdtte ([e-mail]), 11266 Taylor Draper Ln #2517, Austin
 Mac 1.1b9 pre-release         2/29/95 all critical bugs fixed
 Pre-release reports due       3/1/95
             -- Quote from unnamed product status report


+++++++++++++++++++++++++++

>From [e-mail] (Daniele Terdina)
Date: 28 Jun 1995 18:44:16 GMT
Organization: ICTP-Trieste-Italy

In article <[e-mail]>,
[e-mail] (andrew meggs) wrote:

> My life would be much happier if I could call SndDoCommand from
> a Sound callback to tell a sound channel what to do next. The problem
> is, IM-Sound offers the incredibly useless advice that "MOST of
> the available sound commands do not cause SndDoCommand to move
> memory and can therefore be issued at interrupt time."
>
> I have a deep suspicion that bufferCmd might not fall under the
> category of "most", since they talk about using soundCmd before
> interrupt time to preconfigure the channel. Can anyone confirm or
> deny this?

I don't know if it can be done (officially), however I use bufferCmd in
the sound callback routine and I've never had any problems.

--
Daniele Terdina                   e-mail: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Thu, 06 Jul 1995 12:48:51 -0700
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Daniele Terdina) wrote:

> In article <[e-mail]>,
> [e-mail] (andrew meggs) wrote:
>
> > My life would be much happier if I could call SndDoCommand from
> > a Sound callback to tell a sound channel what to do next. The problem
> > is, IM-Sound offers the incredibly useless advice that "MOST of
> > the available sound commands do not cause SndDoCommand to move
> > memory and can therefore be issued at interrupt time."
> >
> > I have a deep suspicion that bufferCmd might not fall under the
> > category of "most", since they talk about using soundCmd before
> > interrupt time to preconfigure the channel. Can anyone confirm or
> > deny this?
>
> I don't know if it can be done (officially), however I use bufferCmd in
> the sound callback routine and I've never had any problems.

You can use the bufferCmd (which is the same as soundCmd) as long as you
do not change the format of the sound being played. For example, you are
playing a non-compressed sound. During the CallBackProc() you cannot then
play a compressed sound because it would attempt to load a decompressor
into memory. This is also true when switching between 8 and 16 bit data.

--
Jim Reekes, Polterzeitgeist |       QuickTime Products R&D
                            |        Sound Manager Expert
Apple Computer, Inc.        | "All opinions expressed are mine, and
2 Infinite Loop  MS 302-3KS |  do not necessarily represent those
Cupertino, CA 95014         |  of my employer, Apple Computer Inc."

---------------------------

>From [e-mail] (Alain Roy)
Subject: Why fuss over OpenDoc?
Date: Sun, 25 Jun 1995 17:56:23 GMT
Organization: None

Recently, while on vacataion, I had time to do some catch up reading. I
read a little about OpenDoc.

I can understand why OpenDoc is cool--for people that wish to create
compound documents. It seems like a neat concept.

However, I'm a programmer and a student. I rarely create compound
documents. Once in a while, I'll write a paper with a single graphic in
it, for which MS Word's graphic tool is sufficent. On the other hand, I
edit a program's source files. I post occaisonally to the net. I write
some email. None of these things seems to me to benefit from having the
ability to edit compound documents.

People seem to be getting very excited about OpenDoc. Could someone
explain to a person like me (who doesn't create complicated documents with
charts and pictures) what there is to get excited about OpenDoc? I have a
feeling that there is something, but I'm not sure what.

This isn't a flame against OpenDoc at all. I just want to understand the fuss.

-alain

+++++++++++++++++++++++++++

>From [e-mail] (Jim Lloyd)
Date: Sun, 25 Jun 1995 12:49:53 -0700
Organization: MelonGem Productions

In article <[e-mail]>,
[e-mail] (Alain Roy) wrote:

>Recently, while on vacataion, I had time to do some catch up reading. I
>read a little about OpenDoc.
>
>I can understand why OpenDoc is cool--for people that wish to create
>compound documents. It seems like a neat concept.
>
>However, I'm a programmer and a student. I rarely create compound
>documents. Once in a while, I'll write a paper with a single graphic in
>it, for which MS Word's graphic tool is sufficent. On the other hand, I
>edit a program's source files. I post occaisonally to the net. I write
>some email. None of these things seems to me to benefit from having the
>ability to edit compound documents.
>
>People seem to be getting very excited about OpenDoc. Could someone
>explain to a person like me (who doesn't create complicated documents with
>charts and pictures) what there is to get excited about OpenDoc? I have a
>feeling that there is something, but I'm not sure what.
>
>This isn't a flame against OpenDoc at all. I just want to understand the fuss.

There are (at least) two possible directions for answers to take:

1) You don't use compound documents very much right now because it's too
difficult to do so.  If it was made simple and natural, you'd find
yourself using compound documents much more often.

2) Thinking of OpenDoc as exclusively a compound document architecture is
a mistake.  OpenDoc provides a mechanism for creating custom applications
from off-the-shelf components.  Think of OpenDoc as a more of a Hypercard
or Visual Basic done right.  Even this viewpoint is somewhat limiting, I
expect, but it's in the right direction.

OpenDoc is a paradigm shift.  It takes a while to fully appreciate what it
can do. I don't claim I've finished making the shift myself, but I've gone
far enough that I can see that many applications that originally didn't
seem appropriate for OpenDoc actually are well-suited when looked at from
the right angle.

Let me provide just one example.  To me, the term "compound document"
somehow makes me want to think of the final printed output.  Compound
documents are created, and then distributed in some static form, most
likely on paper.  Perhaps I'm the only person who reads this connotation
into the term "compound document", but I expect the opposite is true: most
people think of compound documents as being relatively static entities.

OpenDoc documents are living documents.  Each component in the document
can be interactive, not just for the creator of the document, but for all
recipients of the document as well.

Here's an idea for a suite of OpenDoc components (parts) that I'm starting
to work on.  I don't mind giving away this idea, since I expect I may
never have time to do it right (but I would appreciate it if anyone who
tries to do this would notify me).  The idea is inspired by the book
"Design Patterns, Elements of Reusable Object-Oriented Software", by E.
Gamma, R. Helm, R. Johnson, and J. Vlissides (highly recommended!).

In this book, a couple dozen "design patterns" are documented in a
consistent manner.  A chapter is devoted to each pattern.  Each chapter is
structured the same way, with a standard layout of sections, diagrams,
etc.  The layout for describing design patterns has been adopted by a
growing community of computer scientists and engineers for cataloging
design patterns.

My idea is to create three component editors for each of the three diagram
notations that occur in the book (Class Diagram Notation, Object Diagram
Notation, and Interaction Diagram Notation).  A fourth component editor is
required: a styled text editor that supports embedding, though I assume I
won't need to create this component editor, somebody else will do that for
me, allowing me to focus on the diagram editors.

Now, if I simply created each of the three diagram editors, anyone who
wanted to document a new design pattern could simply open a stationery
document that I would provide, and start documenting.  This would be
useful by itself.  However, this results in a static compound document.
The pattern documentor creates a document, and then distributes it.
Recipients of the document might as well just recieve a printed copy,
since the only thing they might do with the document is correct typos, add
notes, etc.

However, suppose each of the diagram editors could use the Open Scripting
Architecture (OSA) to communicate with an application (or OpenDoc
component) like Object Master.  If a design pattern document were shipped
with the Object Master project for the sample code shown in the pattern,
then recipients of the pattern document could use it as a browser to
further explore the sample code.

I am currently working on the OpenDoc Development Framework (ODF), a
cross-platform C++ framework for OpenDoc.  There are numerous design
patterns that occur in ODF.  It would be really cool if each one was
documented in the style described by the book Design Patterns.  If each
pattern was included in our printed documentation, it would be a valuable
addition to our documentation suite.  But if each pattern document was
shipped on the CD along with Object Master projects for all of ODF, it
would provide an ideal way to explore and learn ODF.

- ---------------------------------------------------------------------
Jim Lloyd                                              [e-mail]
Software Consultant                                     v. 415-964-8500
MelonGem Productions                                    f. 415-964-6888
                 "At our convenience, at your expense."

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Sun, 25 Jun 1995 16:47:48 -0800
Organization: In Phase Consulting

[e-mail] (Alain Roy) wrote:

> This isn't a flame against OpenDoc at all. I just want to understand the fuss.

OpenDoc's purpose is to allow the editing of compound documents.
That's it.

The point about OpenDoc is that it is a new programming and user
interface paradigm which is ideally suited to the editing of
documents.

OpenDoc does not address task-oriented issues (such as reading your
on-line mail--though I suppose someone will create a mailer OpenDoc
part), nor does it address 'filter' tasks (tasks which involve the
conversion of input data--say some C source--to output data--say, an
executable program). However, OpenDoc does not make any effort
to address these issues; for such things Apple has in mind preserving
the windowing paradigm. (Though the possibility exists that if
OpenDoc catches on big time, a lot of pressure will exist to
convert even task-oriented programs into OpenDoc parts.)

Personally I don't think OpenDoc is going to catch on in the
way that Apple hopes. Apple has in mind that OpenDoc is the
technological "Microsoft Killer"--that is, they have in mind that
a hundred little developers developing a hundred little parts
will pick Microsoft's monolithic monopoly on office software
(Microsoft Word, Excel, and other packages) to pieces.

Frankly, I don't think that is going to happen. Why? Three reasons.
First, people buy *solutions*, not individual software packages.
And they like to buy all the solutions pre-bundled in one place.
(If that weren't the case, why then is Microsoft Office such
a success?) The idea that a hundred little developers will pick
Microsoft's market apart is absurd--people for the most part are
not going to go out and buy a container part here, a graph
part there, a spread sheet calculator engine over yonder. They
are going to buy a single solution--a single package, maintained
by a single developer house, in a single box. So OpenDoc may serve
as the API gluing Microsoft Office v6 together; so what?

Second, the economic reality of the software market dictates that
only a Microsoft is going to command the resources to advertise,
get shelf space, and provide a distribution channel to sell a lot
of software. That's why Microsoft is so successful--because Bill
Gates has put a lot of time, money, and effort into building
the resources necessary for the advertisements, shelf space, and
distribution channels.

So Microsoft will subcontract even more of it's development
efforts out--so what? Yeah, there are going to be a hundred little
independant contractors building a hundred little OpenDoc parts;
they all will just subcontract for Microsoft. And Novell. And
Apple.

In fact, the economic reality dictates that as more and more
pressure is put on the software development fields by accelerated
technological advances, and by the drive to get even more software
for less money will force large companies like Microsoft,
Apple, Novel and the rest to subcontract more and more of their
work out to independant developers. OpenDoc will help accelerate
this process by providing a unified API for developing the
components of the software.

But the software on the shelf is still going to have "Microsoft"
written all over it.

The third reason why I don't think OpenDoc is going to catch
on is that the market it addresses is so dominated by the
Microsofts of the world that independant developers are not going
to risk losing their shirt in that field, anyways.

Look at me--I do games. I have done a CAD-style editor, but for
the acoustical market. I make my living working for the vertical
markets too small for the Microsofts of the world to make a go
at. Granted, my CAD editor engine is as fine as I have seen
in any commercial CAD package, there is no way in hell I'm going
to pitch the engine up against AutoDesk's AutoCAD. Not because
I couldn't compete technically; I just couldn't compete market-wise.

Do you think I'm going to risk a pretty good living trying to
take on Microsoft? Get real. If Microsoft approaches me and says
"Bill, we need you to develop a new graphing widget for OpenDoc
for the Macintosh and for Windows which can draw cool 3D
bar graphs and allow you to fly through them", then yes, I'll
produce the tool. And I'll produce a damned fine tool, and
I'll be happy when I know that my fine tool appeared in Microsoft's
Office product.

But do you think I'm going to develop the tool on my own and try
to sell it in today's market (with the big players hiring
BBD&O to do their television ads)? Are you crazy?

I *like* putting food on my table.


The upshot of this is that OpenDoc, while a wonderful new programming
and user interface paradigm, probably won't affect many of us
on the net. Unless we really do put together complex, compound
documents for a living.

                                                - Bill

I'm really not this pessimistic, really I'm not! I'm actually a
pretty nice person once you get to know me.

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Mon, 26 Jun 1995 03:15:46 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (William Edward Woody) writes:
>[e-mail] (Alain Roy) wrote:
>> This isn't a flame against OpenDoc at all. I just want to understand the fuss.

>OpenDoc's purpose is to allow the editing of compound documents.
>That's it.
...
>Personally I don't think OpenDoc is going to catch on in the
>way that Apple hopes. ...

>Frankly, I don't think that is going to happen. ...

     There's an active market in Visual Basic buttons (now called
OLE Controls).  That, in fact, is the only software "parts" area that
has developed into a real market.  OpenDoc is supposed to create
a comparable market in the Mac world.

     Unfortunately for Apple, the reason there's a market for OLE Controls
is because people use them to build business applications.  These aren't
typically oriented towards compound documents; they're usually application
specific front ends to databases accessed via SQL or a similar mechanism.
(After all, the primary visual object in the Visual Basic world is the
"form").  So the additional power of OpenDoc over OLE may not be that valuable.
Macs aren't a major platform for semi-custom business applications anyway.

    Remember Publish and Subscribe?  We have limited compound document
capability now, and nobody uses it.  Nor has there been any visible
demand for extensions to it from the user community.

    As a final nail in the coffin, the usual suggestion for "compound
documents" involves tying together spreadsheets and word processor documents.
And who makes the leading spreadsheet and the leading word processor for
the Mac?  Microsoft.  Are they going to support OpenDoc?  No.

                                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Mon, 26 Jun 1995 15:12:04 GMT
Organization: BSD -- Academic Computing

In article <[e-mail]>,
[e-mail] (Alain Roy) wrote:

> Recently, while on vacataion, I had time to do some catch up reading. I
> read a little about OpenDoc.
>
> I can understand why OpenDoc is cool--for people that wish to create
> compound documents. It seems like a neat concept.
>
> However, I'm a programmer and a student. I rarely create compound
> documents. Once in a while, I'll write a paper with a single graphic in
> it, for which MS Word's graphic tool is sufficent. On the other hand, I
> edit a program's source files. I post occaisonally to the net. I write
> some email. None of these things seems to me to benefit from having the
> ability to edit compound documents.

Say you are a student in biology. And you are writing a paper on say,
protien folding. And your have a neat OpenDoc Part that does molecular
graphics. You can include, instead of a series of pictures in your paper,
a molecular graphic, that can be manipulated in real time. And if DSOM
ever comes around you could do real time dynamics on Cray, or some other
big time iron machine so that your reader can read you paper and your
simulation will be tightly coupled with the words. The idea of to allow
for new modes of combing data.

> People seem to be getting very excited about OpenDoc. Could someone
> explain to a person like me (who doesn't create complicated documents with
> charts and pictures) what there is to get excited about OpenDoc? I have a
> feeling that there is something, but I'm not sure what.

You are allowing yourself to be confined by what can be done today.
Personally I can think of hundreds of uses of this. By combining things
that don't normally go together.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Mon, 26 Jun 1995 15:25:37 GMT
Organization: BSD -- Academic Computing

In article <woody-2506951647480001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> [e-mail] (Alain Roy) wrote:
>
> > This isn't a flame against OpenDoc at all. I just want to understand
the fuss.
>
[ stuff deleted ]
> The upshot of this is that OpenDoc, while a wonderful new programming
> and user interface paradigm, probably won't affect many of us
> on the net. Unless we really do put together complex, compound
> documents for a living.

You are missing the point. While OpenDoc is NOT the silver bullet the
ideas that folks will come up with for parts WILL be. Wether or not it
will actually be a Microsoft killer remains to be seen. We are currently
limited by our vision, but it has never been the OS that has sold
computers (despite what Apple and Microsoft say). It has always been
applications. Granted the OS is what makes the apps cool. OpenDoc has a
great deal of potential, but it is also a move away from the target of our
documents ending up on paper. There are lots of smart folks out there who
have an idea of what OpenDoc can do, and I am sure in a few years folks
will wonder how we lived without it (as we do with Windowed Event Driven
OS's now.)

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jim Lloyd)
Date: Mon, 26 Jun 1995 09:13:52 -0700
Organization: MelonGem Productions

In article <woody-2506951647480001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

>[e-mail] (Alain Roy) wrote:
>
>> This isn't a flame against OpenDoc at all. I just want to understand
the fuss.
>
>OpenDoc's purpose is to allow the editing of compound documents.
>That's it.

No, that's not it.  It's a common misconception, but compound documents
are only part of the picture, the part easiest to describe and latch onto.

>The point about OpenDoc is that it is a new programming and user
>interface paradigm which is ideally suited to the editing of
>documents.

OpenDoc provides a mechanism for presenting a componentized
user-interface.  The interface may have state that is stored in a
"document".  This will result in "compound documents", but it will also
result in other kinds of applications.

>OpenDoc does not address task-oriented issues (such as reading your
>on-line mail--though I suppose someone will create a mailer OpenDoc
>part), nor does it address 'filter' tasks (tasks which involve the
>conversion of input data--say some C source--to output data--say, an
>executable program). However, OpenDoc does not make any effort
>to address these issues; for such things Apple has in mind preserving
>the windowing paradigm.

OpenDoc itself may not address some of these issues, but it does not
preclude them.  The same can be said for the "windowing paradigm".
Apple's "windowing paradigm" does not addressing filtering, does it?

>Personally I don't think OpenDoc is going to catch on in the
>way that Apple hopes. Apple has in mind that OpenDoc is the
>technological "Microsoft Killer"--that is, they have in mind that
>a hundred little developers developing a hundred little parts
>will pick Microsoft's monolithic monopoly on office software
>(Microsoft Word, Excel, and other packages) to pieces.

I don't know where you got this picture.  Is there some marketing material
from Apple that led you to believe this?  It doesn't match my picture of
what Apple is trying to do at all.

>Frankly, I don't think that is going to happen. Why? Three reasons.
>First, people buy *solutions*, not individual software packages.

Software integrators will be able to take a set of part editors, package
them together as some stationery, applescripts, etc., and package them
into a solution, addessed to vertical markets.  Horizontal markets will be
addressed by developers who develop well-crafted parts for common tasks
like word processing, graphics, and (surprise!) CAD.

>Second, the economic reality of the software market dictates that
>only a Microsoft is going to command the resources to advertise,
>get shelf space, and provide a distribution channel to sell a lot
>of software. That's why Microsoft is so successful--because Bill
>Gates has put a lot of time, money, and effort into building
>the resources necessary for the advertisements, shelf space, and
>distribution channels.

Man, is this a pessimistic point of view!  How long were you in traction
when the Microsoft steam roller crushed all of the bones in your body?

Last time I walked into any software store, or flipped through any
software catalog, Microsoft products were certainly prominent, but they
had a small percentage of total shelf space or catalog pages.

>In fact, the economic reality dictates that as more and more
>pressure is put on the software development fields by accelerated
>technological advances, and by the drive to get even more software
>for less money will force large companies like Microsoft,
>Apple, Novel and the rest to subcontract more and more of their
>work out to independant developers. OpenDoc will help accelerate
>this process by providing a unified API for developing the
>components of the software.

Aha! I see a ray of hope!

>But the software on the shelf is still going to have "Microsoft"
>written all over it.

Whoops! How long did you say you were in traction?

>The third reason why I don't think OpenDoc is going to catch
>on is that the market it addresses is so dominated by the
>Microsofts of the world that independant developers are not going
>to risk losing their shirt in that field, anyways.
>
>Look at me--I do games. I have done a CAD-style editor, but for
>the acoustical market. I make my living working for the vertical
>markets too small for the Microsofts of the world to make a go
>at. Granted, my CAD editor engine is as fine as I have seen
>in any commercial CAD package, there is no way in hell I'm going
>to pitch the engine up against AutoDesk's AutoCAD. Not because
>I couldn't compete technically; I just couldn't compete market-wise.

Man, have you missed the boat! If I were you with a CAD editor that was
"as fine as any commercial CAD package", I'd be seriously looking to turn
it into a part editor.  Then, any software integrator who needs a CAD
element might turn to you for that portion of their package.  Here's your
chance to beat the big market players to a new market.  Sure, Apple or
Novell (or even Microsoft) might release *your* CAD editor with *their*
name on the box, but *your* name will still be in the about box, and *you*
will receive royalties from *their* sales and marketing efforts.  What's
wrong with that, Mr. Pessimisism?

>Do you think I'm going to risk a pretty good living trying to
>take on Microsoft? Get real. If Microsoft approaches me and says
>"Bill, we need you to develop a new graphing widget for OpenDoc
>for the Macintosh and for Windows which can draw cool 3D
>bar graphs and allow you to fly through them", then yes, I'll
>produce the tool. And I'll produce a damned fine tool, and
>I'll be happy when I know that my fine tool appeared in Microsoft's
>Office product.

Aha! I see the glass is only half empty after all.  Hey Bill, what's the
chance that Microsoft will ask you to develop a new widget for them, as
opposed to them asking you to use the widget you've already created?
Multiply this now by a factor of one hundred or more to take into account
the the rest of the world that may have a need for your widget, but
doesn't have the time or resources to create it on their own.

>But do you think I'm going to develop the tool on my own and try
>to sell it in today's market (with the big players hiring
>BBD&O to do their television ads)? Are you crazy?

If you already have a CAD engine, converting it to OpenDoc is probably not
a major effort (take a look at the ODFDraw part example, included with the
OpenDoc Development Framework).  Then, all you have to do is take the
effort to appear in the part catalogs that will appear, and send a demo
version of your part editor to macgifts.  Then, with luck, one of the big
players will decide to use your part in one of their packages, and you'll
get a free ride from the BBD&O adds.

>I'm really not this pessimistic, really I'm not! I'm actually a
>pretty nice person once you get to know me.

Glad to hear it!

-Jim

- ---------------------------------------------------------------------
Jim Lloyd                                              [e-mail]
Software Consultant                                     v. 415-964-8500
MelonGem Productions                                    f. 415-964-6888
                 "At our convenience, at your expense."

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 26 Jun 1995 16:07:57 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Alain Roy) wrote:

< Recently, while on vacataion, I had time to do some catch up reading. I
< read a little about OpenDoc.
<
< I can understand why OpenDoc is cool--for people that wish to create
< compound documents. It seems like a neat concept.
<
< However, I'm a programmer and a student. I rarely create compound
< documents. Once in a while, I'll write a paper with a single graphic in
< it, for which MS Word's graphic tool is sufficent. On the other hand, I
< edit a program's source files. I post occaisonally to the net. I write
< some email. None of these things seems to me to benefit from having the
< ability to edit compound documents.
<
< People seem to be getting very excited about OpenDoc. Could someone
< explain to a person like me (who doesn't create complicated documents with
< charts and pictures) what there is to get excited about OpenDoc? I have a
< feeling that there is something, but I'm not sure what.
<
< This isn't a flame against OpenDoc at all. I just want to understand the fuss.
<
< -alain

Imagine being able to have a spell checker part and grammer checker part
that you can use easily in your newsreader and mailreader apps.  Sheesh,
just imagine only having to have one spell checker on your machine,
instead of the three or four many people now have on their machines.

I think that we may see control panel type parts.  Things that do
something that you might want to put together in a single container.  I
think that apple is working on network controls and internet parts that
you will be able to mix and match.

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Alain Roy)
Date: Mon, 26 Jun 1995 17:04:22 GMT
Organization: None

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

>Imagine being able to have a spell checker part and grammer checker part
>that you can use easily in your newsreader and mailreader apps.  Sheesh,
>just imagine only having to have one spell checker on your machine,
>instead of the three or four many people now have on their machines.

That sounds excellent to me.

I thought that Apple Events/Applescripting were supposed to provide that
already. Can you explain how OpenDoc makes it easier to add than just
sending an AppleEvent? I believe you, I'm just not sure why it's easier,
or people are more likely to use it.

-alain

+++++++++++++++++++++++++++

>From [e-mail] (R Shapiro)
Date: Mon, 26 Jun 1995 13:26:44 -0400
Organization: Bolt Beranek & Newman

In article <[e-mail]>, [e-mail]
(Jim Lloyd) wrote:

>OpenDoc provides a mechanism for presenting a componentized
>user-interface.  The interface may have state that is stored in a
>"document".  This will result in "compound documents", but it will also
>result in other kinds of applications.


I'm assuming, since we're talking Apple vs MSoft here, that this will be
cleaner than Ole. Is it? How does it differ functionally?

--
rs/[e-mail]

+++++++++++++++++++++++++++

>From Malcolm Pradhan <[e-mail]>
Date: 26 Jun 1995 18:08:53 GMT
Organization: Section on Medical Informatics, Stanford University

In article <[e-mail]> Alain Roy,
[e-mail] writes:
> I can understand why OpenDoc is cool--for people that wish to create
> compound documents. It seems like a neat concept.

I must agree with Jim Lloyd's OpenDoc vision. When I first saw an
OpenDoc demo I yawned and thought "ClarisWorks already does this!" and
wandered off. A few weeks ago I sat through another demo (which was
mainly motivated by my interest in SOM), and I have completely turned
around on OpenDoc.

The demo began with the usual compound document stuff, and it was still
boring. The really interesting stuff came with the custom solution
demos, eg. linking a database part with a graph part, and some button
parts which sent queries to the database part. I suppose this is still
a compound document but not in the usual interpretation.

The thing that was really exciting was Claris' virtual controls (?).
Claris had removed the user interface from their "work" code, in this
case a drawing program. The user interface communicated to the drawing
program via a set of semantic events (same as an AppleScript suite), so
the user interface parts could be changed to create custom solutions.
First they slotted in a power user interface to their drawing part
(similar to ClarisDraw), then dragged another user interface part from
a palette to create a child's drawing package (including animated teddy
bears, crayons for choosing colors etc). Meanwhile, the underlying
drawing code remained the same.

Cyberdog was also an interesting demo, but I found the custom solution
stuff more useful than better ways to jump around the net. OpenDoc will
make any tool that allows embedding to be a kind of super Visual Basic.
If HyperCard is made into a container (which I understand it will), it
suddenly becomes an amazingly useful tool -- custom code can share the
screen, have globals, have persistent storage, and parts can be
scripted.

Regarding filters, parts can be faceless (although the standards for
this are still being sorted out). This means you could write a drag and
drop script that actives a suite of filter parts which don't have a
user interface. Even better, you could link together various filter
icons and save the document as a drag and drop filter. You have to
shift your view a bit.

I think OpenDoc is a great move by Apple, but it is up to them to get
some really cool demonstrations out to destroy the traditional compound
document image that limits people's image of this technology.


 Regards,
 Malcolm

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Tue, 27 Jun 1995 12:09:39 +1200 (NZDT)
Organization: (none)

[e-mail] (John Nagle) writes:
>      Unfortunately for Apple, the reason there's a market for OLE Controls
> is because people use them to build business applications.  These aren't
> typically oriented towards compound documents; they're usually application
> specific front ends to databases accessed via SQL or a similar mechanism.
> (After all, the primary visual object in the Visual Basic world is the
> "form").  So the additional power of OpenDoc over OLE may not be that valuable.
> Macs aren't a major platform for semi-custom business applications anyway.

That's true now, although that's what I earn my living doing.

OpenDoc is not going to make the Mac any less attractive to that market
than it is now.  It could make it *much* more attractive.  I'm certainly
hoping to make money from OpenDoc.


>     Remember Publish and Subscribe?  We have limited compound document
> capability now, and nobody uses it.  Nor has there been any visible
> demand for extensions to it from the user community.

The stockbroking firm who's systems I manage uses P&S *extensively* to tie
together source data from spreadsheets to specialised analysis and graphing
and report programs (written by me) and then into page layout/word
processing software to tie it all togther for final printing.

The P&S implementations in Word and Excel suck in both time and space usage,
and lose links from time to time, but it enables things you couldn't
otherwise do.  (Well, maybe with AppleScript, but that's much newer and is
process-oriented rather than data oriented)


>     As a final nail in the coffin, the usual suggestion for "compound
> documents" involves tying together spreadsheets and word processor documents.
> And who makes the leading spreadsheet and the leading word processor for
> the Mac?  Microsoft.  Are they going to support OpenDoc?  No.

Well, a) OLE stuff can be used by OpenDoc, and b) maybe that's agood opportunity
for others to get another toehold for these things on the Mac...

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 26 Jun 1995 20:27:26 GMT
Organization: Primenet [phone]

Jerome Jahnke ([e-mail]) wrote:
[snipt]
: Say you are a student in biology. And you are writing a paper on say,
: protien folding. And your have a neat OpenDoc Part that does molecular
: graphics. You can include, instead of a series of pictures in your paper,
: a molecular graphic, that can be manipulated in real time. And if DSOM
: ever comes around you could do real time dynamics on Cray, or some other
: big time iron machine so that your reader can read you paper and your
: simulation will be tightly coupled with the words. The idea of to allow
: for new modes of combing data.
:


And things can be even better than most people realize. The OSA is the
"standard" model for linking parts. However, OpenDOc allows for custom
communication between parts that would go MUCH faster than the
AppleScript paradigm would suggest.

So fast, in fact, that you could create parts that would serve as tools
in one collection, but in a slightly different collection, would serve as
the display of what you created with the tool-collection.

The classic example is a Thesaurus. You could have a thesaurus part that
would interract with a word-processor and provide "real time" suggestions
for alternate words using the OSA. However, this same part could be used
as part of the AI engine for a game. If the OSA wasn't fast enough,
you could "roll your own" communications method that would allow much
faster exchange of data than the human-oriented OSA would provice, and
allow parsing of phrases in a Zork-like game that allowed nearly
unlimited synonyms.


: > People seem to be getting very excited about OpenDoc. Could someone
: > explain to a person like me (who doesn't create complicated documents with
: > charts and pictures) what there is to get excited about OpenDoc? I have a
: > feeling that there is something, but I'm not sure what.

: You are allowing yourself to be confined by what can be done today.
: Personally I can think of hundreds of uses of this. By combining things
: that don't normally go together.


Or combining them in ways that no-one has thought of, because they are
still bound by the old paradigm.

It's object-oriented vs structured programming all over again, but bigger
this time.


--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Mon, 26 Jun 1995 13:58:29 -0800
Organization: In Phase Consulting

In article <[e-mail]>,
[e-mail] (Jerome Jahnke) wrote:

> Say you are a student in biology. And you are writing a paper on say,
> protien folding. And your have a neat OpenDoc Part that does molecular
> graphics. You can include, instead of a series of pictures in your paper,
> a molecular graphic, that can be manipulated in real time. And if DSOM
> ever comes around you could do real time dynamics on Cray, or some other
> big time iron machine so that your reader can read you paper and your
> simulation will be tightly coupled with the words. The idea of to allow
> for new modes of combing data.

But (to be contrary), you can do that now.

Just paste a QuickTime movie into your document.

Why wait for OpenDoc?

Oh (he says) you want to do some form of dynamic update from your Cray?
(Like there are thousands of business users out there who have Crays
they are just dying to incorporate animations from.)

Then just make your simulation package compatable with publish and subscribe.

OpenDoc does not allow you to do things you couldn't before, (like
dynamic update); it only allows you to create compound documents which
change the menu bar and the tools (and underlying executing application part)
when you click on part of a compound document.

Just like OLE v2.0, it does *not* add features that cannot be added today,
except for the compound document user interface. (That is, the only thing
it eliminates is the major task swap and reshuffling of windows--this
is replaced by a major task swap when you select the picture you
put into your text document.)

If we really wanted, needed, and required dynamic update of documents,
or any of a half-dozen other features that OpenDoc is being touted for,
we _could_have_done_it_already, with AppleEvents and Publish and Subscribe.
(Which have been around for over 2 _years_ now.)

                                                - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Mon, 26 Jun 1995 14:00:40 -0800
Organization: In Phase Consulting

[e-mail] (Jerome Jahnke) wrote:

> ... There are lots of smart folks out there who
> have an idea of what OpenDoc can do, and I am sure in a few years folks
> will wonder how we lived without it (as we do with Windowed Event Driven
> OS's now.)

Or publish and subscribe.

Or AppleEvents.

Or Apple Scripting.

Or QuickDraw GX.

*sigh*

I can't live with ^H^H^H^H^Hwithout any of them now.

                                                - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 26 Jun 1995 17:41:05 -0500
Organization: Random


In article <[e-mail]>,
[e-mail] (Alain Roy) wrote:

> However, I'm a programmer and a student. I rarely create compound
> documents. Once in a while, I'll write a paper with a single graphic in
> it, for which MS Word's graphic tool is sufficent. On the other hand, I
> edit a program's source files. I post occaisonally to the net. I write
> some email. None of these things seems to me to benefit from having the
> ability to edit compound documents.

Yes, you would.

For e-mail, something like Eudora could be constructed as a collection of
nickname, mail collection, text editor, and transmission parts. Same thing
for news reading. Not to mention that the mail you would send could be an
OpenDoc document.

The "application" the user buys is a piece of stationery of a document with
the pieces already put together into something that looks like an
application. It could even be several pieces of stationery; one for sending
a new letter, and one for reading mail.

Similarly; for a web browser, compound documents is what it's all about.
And, to an extent, even writing applications in a visual editor of some
kind compounds "parts" in the form of text boxes, scroll bars, radio
buttons etc.

Cheers,

                                / h+


--
 Jon Wdtte ([e-mail]), 11266 Taylor Draper Ln #2517, Austin
 Mac 1.1b9 pre-release         2/29/95 all critical bugs fixed
 Pre-release reports due       3/1/95
             -- Quote from unnamed product status report


+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 26 Jun 1995 17:41:08 -0500
Organization: Random


In article <woody-2506951647480001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> OpenDoc does not address task-oriented issues (such as reading your
> on-line mail--though I suppose someone will create a mailer OpenDoc
> part), nor does it address 'filter' tasks (tasks which involve the

I think you are wrong. OpenDoc provides good interfaces for several task-
and filter-like things, including mail, news and web browsing.

> Personally I don't think OpenDoc is going to catch on in the
> way that Apple hopes. Apple has in mind that OpenDoc is the
> technological "Microsoft Killer"--that is, they have in mind that
> a hundred little developers developing a hundred little parts
> will pick Microsoft's monolithic monopoly on office software
> (Microsoft Word, Excel, and other packages) to pieces.

That's only part of it.

> Frankly, I don't think that is going to happen. Why? Three reasons.
> First, people buy *solutions*, not individual software packages.

Yes, and with a hundred of different parts to choose from, it's
substantially easier for small *publishers* to pick out the pieces they
want, license them, glue them together into stationery and sell highly
specialized solutions. Say, a corporate lawyer firm word processor, or a
mortgage lender firm spreadsheet. If the customer has a choise between a
general-purpose solution, and one already set-up for his individual needs,
which one does he choose? Can Microsoft really offer 4300 different
configurations of Office?

Part developers make money off licensing to publishers. Publishers make
money off sales. And power users can take the solutions apart; substituting
and customizing as they wish.

Cheers,

                                        / h+


--
 Jon Wdtte ([e-mail]), 11266 Taylor Draper Ln #2517, Austin
 Mac 1.1b9 pre-release         2/29/95 all critical bugs fixed
 Pre-release reports due       3/1/95
             -- Quote from unnamed product status report


+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 26 Jun 1995 22:40:41 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Alain Roy) wrote:

< In article <[e-mail]>,
< [e-mail] (Brian Stern) wrote:
<
< >Imagine being able to have a spell checker part and grammer checker part
< >that you can use easily in your newsreader and mailreader apps.  Sheesh,
< >just imagine only having to have one spell checker on your machine,
< >instead of the three or four many people now have on their machines.
<
< That sounds excellent to me.
<
< I thought that Apple Events/Applescripting were supposed to provide that
< already. Can you explain how OpenDoc makes it easier to add than just
< sending an AppleEvent? I believe you, I'm just not sure why it's easier,
< or people are more likely to use it.
<
< -alain

If you want to add spell checking ability to a program like a newsreader
today the author has to provide hooks for it in the application.  It can
be done in one of a few ways:

The newsreader would have to support a spellchecking engine and either
compile the spellcheck engine into the newsreader or communicate with it
directly by apple events.

It could also be done by an extension that fooled with the clipboard and
spellchecked text that was selected.

It could also be done by a standalone spellcheck app that could
communicate with the newsreader and get all the text in the frontmost
window or in the selection.

With opendoc the newsreader just has to contain code so that it is a
container app.  Apparently this is boilerplate code and most likely a lot
of apps will become container apps with little cost or pain.  Once the
newsreader is a container app then you just add the spellcheck/grammer
check part to a window that you are using to compose your message and it
will just work.

I think that appleEvents have paved the way for this sort of thing but
still most apps are based on this monolithic be-all do-all model.  Opendoc
will allow better communication between code written by different authors
and make it easier to do things to the data in a document that the authors
of the container app never planned on.

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 26 Jun 1995 22:55:37 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <woody-2606951358290001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

< In article <[e-mail]>,
< [e-mail] (Jerome Jahnke) wrote:
<
< > Say you are a student in biology. And you are writing a paper on say,
< > protien folding. And your have a neat OpenDoc Part that does molecular
< > graphics. You can include, instead of a series of pictures in your paper,
< > a molecular graphic, that can be manipulated in real time. And if DSOM
< > ever comes around you could do real time dynamics on Cray, or some other
< > big time iron machine so that your reader can read you paper and your
< > simulation will be tightly coupled with the words. The idea of to allow
< > for new modes of combing data.
<
< But (to be contrary), you can do that now.
<
< Just paste a QuickTime movie into your document.

Can I paste a QuickTime movie into any document?  How about a NewsWatcher
document? a CodeWarrior document?

<
< Why wait for OpenDoc?
<
< Oh (he says) you want to do some form of dynamic update from your Cray?
< (Like there are thousands of business users out there who have Crays
< they are just dying to incorporate animations from.)
<
< Then just make your simulation package compatable with publish and subscribe.
<
< OpenDoc does not allow you to do things you couldn't before, (like
< dynamic update); it only allows you to create compound documents which
< change the menu bar and the tools (and underlying executing application part)
< when you click on part of a compound document.

What if I don't like the table editor in PageMaker but I like the one in
Word.  How can I copy my word tables into PageMaker?  Guess what, I
can't.  Why?  Because they have incompatible formats.  And of course I
can't rewrite these tow apps to make this work.

But if I had a table editor part that I liked and PageMaker was a
container app (like I'm sure it will be) then I can use my table editor
part in PageMaker or any other app that is a container app.  That is
something that OpenDoc will allow me to do that you can't do today.

This huge problem of proprietary formats for data will be vastly reduced.

<
< Just like OLE v2.0, it does *not* add features that cannot be added today,
< except for the compound document user interface. (That is, the only thing
< it eliminates is the major task swap and reshuffling of windows--this
< is replaced by a major task swap when you select the picture you
< put into your text document.)
<
< If we really wanted, needed, and required dynamic update of documents,
< or any of a half-dozen other features that OpenDoc is being touted for,
< we _could_have_done_it_already, with AppleEvents and Publish and Subscribe.
< (Which have been around for over 2 _years_ now.)
<
<                                                 - Bill
<
< --
< William Edward Woody  |  e-mail: [e-mail]
< In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
< 337 W. California #4  |  Fax:    [phone]
< Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From Karl Armstrong <[e-mail]>
Date: 26 Jun 1995 21:27:08 GMT
Organization: Computing Devices Int.

Jim Lloyd wrote:
>>Look at me--I do games.

I'm not an expert in OpenDoc, but I am a programmer with some interest in it.
This statement got me thinking about how OD might apply to games.

I think it is very likely that someone will come up with a component based game
system that can be added to. Think of all the add-ons available for Doom.
Doom's "open" architecure consists of a maze editor. Now image a game where
innovative programmers could add new rules or entirely new capabilities. How
about a strategic type wargame that someone can add a tactical/arcade module
too? Without getting into anymore specifics, I think you see the point. A OD
module does not nescesarily have to have a strict visual component; it's really
an advanced sort of IPC. The possiblities are endless.

--
Karl Arsmtrong
Computing Devices Int.
[phone]
[phone] (fax)


+++++++++++++++++++++++++++

>From [e-mail] (Kristopher Johnson)
Date: Mon, 26 Jun 1995 21:04:14 -0400
Organization: Sleepless Night Software

In article <woody-2606951358290001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> Just paste a QuickTime movie into your document.
>
> Why wait for OpenDoc?
>
> Oh (he says) you want to do some form of dynamic update from your Cray?
> (Like there are thousands of business users out there who have Crays
> they are just dying to incorporate animations from.)
>
> Then just make your simulation package compatable with publish and subscribe.

Yeah, but an advantage of OpenDoc is that developers won't have to release
new versions of their software when new technologies like QuickTime,
Publish/Subscribe, or AppleScript come out.  By creating an OpenDoc part,
a developer will be able to support features that haven't even been
invented yet!

--
Kristopher Johnson
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lonny Walker)
Date: 27 Jun 1995 01:26:11 GMT
Organization: Hughes Aircraft Co. - Radar Systems

In article <woody-2606951358290001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

[snip]
>
> Why wait for OpenDoc?
>
> Oh (he says) you want to do some form of dynamic update from your Cray?
> (Like there are thousands of business users out there who have Crays
> they are just dying to incorporate animations from.)
>
> Then just make your simulation package compatable with publish and subscribe.
>
> OpenDoc does not allow you to do things you couldn't before, (like
> dynamic update); it only allows you to create compound documents which
> change the menu bar and the tools (and underlying executing application part)
> when you click on part of a compound document.
>
> Just like OLE v2.0, it does *not* add features that cannot be added today,
> except for the compound document user interface. (That is, the only thing
> it eliminates is the major task swap and reshuffling of windows--this
> is replaced by a major task swap when you select the picture you
> put into your text document.)
>
> If we really wanted, needed, and required dynamic update of documents,
> or any of a half-dozen other features that OpenDoc is being touted for,
> we _could_have_done_it_already, with AppleEvents and Publish and Subscribe.
> (Which have been around for over 2 _years_ now.)
>
>                                                 - Bill


You're right, most of those things can be done today, but OpenDoc
potentially offers a better solution. The end product I really want is a
picture in my presentation; everything else are the steps required to get
there. Some problems you can't even automate since some software doesn't
supports scripting or the software may not exist.

For the custom analysis tasks that I write, OpenDoc provides a frame work
that allows me to easily achive my goals. Besides the analysis engine, all
I need to support is drawing, printing, editing of my data, and saving to
disk. Sure, I could use one of the existing frame works, spend alot of
time, and write a full blown application, but, thats not the end result I
need.

For the small, specialized parts that I'm interested in OpenDoc will fit
the bill and I'm looking forward to it's final release. Until then I'll
get the job done as you suggested, but, my eye is on the future.

Lonny

--
Lonny Walker                     |  email: [e-mail]
Hughes Aircraft Co.              |
Radar and Communication Systems  |

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Tue, 27 Jun 1995 02:14:38 GMT
Organization: BSD -- Academic Computing

In article <woody-2606951358290001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> In article <[e-mail]>,
> [e-mail] (Jerome Jahnke) wrote:
>
> > Say you are a student in biology. And you are writing a paper on say,
> > protien folding. And your have a neat OpenDoc Part that does molecular
> > graphics. You can include, instead of a series of pictures in your paper,
> > a molecular graphic, that can be manipulated in real time. And if DSOM
> > ever comes around you could do real time dynamics on Cray, or some other
> > big time iron machine so that your reader can read you paper and your
> > simulation will be tightly coupled with the words. The idea of to allow
> > for new modes of combing data.
>
> But (to be contrary), you can do that now.
>
> Just paste a QuickTime movie into your document.

Really? Can you take the movie, and more to an abitray angle, say one that
or change the view? Or can you get interested in what you are looking at
and click on it and have it hilight a sequence of atoms and point you back
into your document where those are talked about?? While you can have a
movie running a canned demo in a movie, educationally it is more powerful
to take the movie as a jumping off point instead of the end, which is what
a Quicktime Movie is, you can't re-enter the query stream from a QuickTime
movie, you can only sit back and watch the movie.

> Why wait for OpenDoc?
>
> Oh (he says) you want to do some form of dynamic update from your Cray?
> (Like there are thousands of business users out there who have Crays
> they are just dying to incorporate animations from.)

You would be suprised the sorts of resources that sit on the net doing
nothing all day. Here at the U of Chicago in our open access lab we have 6
SGI Indigo2's hanging out all day doing nothing... Lots of raw processing
power just sitting there waiting to be used. We will also have an ATM line
hooked up to a big super computer at the Fermi Institute with a fair bit
of CPU time on it. The ATM link is being tested next week. And yes, we run
molecular simulations on the machine.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Tue, 27 Jun 1995 02:20:31 GMT
Organization: BSD -- Academic Computing

In article <woody-2606951400400001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> [e-mail] (Jerome Jahnke) wrote:
>
> > ... There are lots of smart folks out there who
> > have an idea of what OpenDoc can do, and I am sure in a few years folks
> > will wonder how we lived without it (as we do with Windowed Event Driven
> > OS's now.)
>
> Or publish and subscribe.

Which quite a few folks use. I use it quite a bit in software I write.

> Or AppleEvents.

Which lots of folks use. I also use this quite a bit becuase I my Apps are
also Applescriptable AND AppleGuideable. The only problem with this
technology is that you force your user base to adopt a minimum level of
software

> Or Apple Scripting.

Which goes hand in hand with Apple Events. Most of the applications I use
use are Applescriptable. And oddly enough I script them all as well. Don't
know where you have been in regards to this.

> Or QuickDraw GX.

How does QuickDraw GX compare to OpenDoc? Personally I don't use it, but
then I got 4 years worth of 3D graphics code sitting on my disc that does
not use much at all of the MacToolbox. However I am considering QuickDraw
3D for new stuff if only becuase it will give me access to hardware
support for 3D as it becomes available on the mac.

> *sigh*
>
> I can't live with ^H^H^H^H^Hwithout any of them now.

Which is just great. If what you do works, cool. No one is knocking down
your door forcing you to use it, although your users may in the future, or
they may not.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Mon, 26 Jun 1995 19:58:03 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:
> Can I paste a QuickTime movie into any document?  How about a NewsWatcher
> document? a CodeWarrior document?

Something that would be cool is an OpenDoc document, that actually has
hooks to various QuickTime tools and graphics presentation views, so that
I could use the tools for a movie, show statistics and such, and even have
all this documented on the same page.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                 Private activities on Internet.
http://dts.apple.com/sandvik/sandvik.html

+++++++++++++++++++++++++++

>From [e-mail] (Jim Lloyd)
Date: Mon, 26 Jun 1995 21:49:27 -0700
Organization: MelonGem Productions

In article <woody-2606951358290001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

>If we really wanted, needed, and required dynamic update of documents,
>or any of a half-dozen other features that OpenDoc is being touted for,
>we _could_have_done_it_already, with AppleEvents and Publish and Subscribe.
>(Which have been around for over 2 _years_ now.)

This reminds me of a well-known true story, though I forget some details:

Once upon a time, some company found itself with a new technology, the
"dry photocopy process".  The company decided to do some market research
to decide if it could exploit this technology.  It did a market survey
based upon the closest competing technology: carbon copies.  It discovered
that carbon copies weren't used very often, from which they concluded that
the dry photo copy process would never yield a significant profit.  They
therefore sold the technology to some fledgling little company.

That fledgling little company was Xerox.

OpenDoc builds upon AppleEvents and Publish and Subscribe (and Bento and
SOM and  other technolgies) and creates something that is more than the
sum of its parts.  It results in something that has significantly more
bang for the buck than Publish and Subscribe.  With Publish and Subscribe,
each subscribing application must fully implement a "part editor" for
every data type it wishes to subscribe to, or settle with viewing PICTs of
the data.  With OpenDoc, containers need not known anything about their
embedded content, with no penalty to the user.  The difference between
these two technologies is, from my point of view, greater than the
difference between carbon copies and xerox photocopies.

- ---------------------------------------------------------------------
Jim Lloyd                                              [e-mail]
Software Consultant                                     v. 415-964-8500
MelonGem Productions                                    f. 415-964-6888
                 "At our convenience, at your expense."

+++++++++++++++++++++++++++

>From [e-mail] (Jim Lloyd)
Date: Mon, 26 Jun 1995 22:01:22 -0700
Organization: MelonGem Productions

In article <3sn8nc$[e-mail]>, Karl Armstrong
<[e-mail]> got his attributions wrong:

>Jim Lloyd wrote:
 ^^^^^^^^^
>>>Look at me--I do games.

No, I didn't say the above. William Edward Woody said it.

>I'm not an expert in OpenDoc, but I am a programmer with some interest in it.
>This statement got me thinking about how OD might apply to games.
>
>I think it is very likely that someone will come up with a component based game
>system that can be added to. Think of all the add-ons available for Doom.
>Doom's "open" architecure consists of a maze editor. Now image a game where
>innovative programmers could add new rules or entirely new capabilities. How
>about a strategic type wargame that someone can add a tactical/arcade module
>too? Without getting into anymore specifics, I think you see the point. A OD
>module does not nescesarily have to have a strict visual component; it's really
>an advanced sort of IPC. The possiblities are endless.
>
>--
>Karl Arsmtrong
>Computing Devices Int.
>[phone]
>[phone] (fax)

- ---------------------------------------------------------------------
Jim Lloyd                                              [e-mail]
Software Consultant                                     v. 415-964-8500
MelonGem Productions                                    f. 415-964-6888
                 "At our convenience, at your expense."

+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Mon, 26 Jun 1995 23:41:25 -0800
Organization: Oracle Corp.

In article <woody-2606951358290001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

>In article <[e-mail]>,
>[e-mail] (Jerome Jahnke) wrote:
>
>> Say you are a student in biology. And you are writing a paper on say,
>> protien folding. And your have a neat OpenDoc Part that does molecular
>> graphics. You can include, instead of a series of pictures in your paper,
>> a molecular graphic, that can be manipulated in real time. And if DSOM
>> ever comes around you could do real time dynamics on Cray, or some other
>> big time iron machine so that your reader can read you paper and your
>> simulation will be tightly coupled with the words. The idea of to allow
>> for new modes of combing data.
>
>But (to be contrary), you can do that now.
>
>Just paste a QuickTime movie into your document.

That presupposes that your document editor handles QuickTime movies.
But do you have any document editors that can handle Quickdraw3D
images?  I think not.  How long will it take before all editors you
use rev to support Quickdraw 3D?  A damn long time.  How long
will it be before you can add Quickdraw 3D images into an OpenDoc-enabled
application?  About 10 seconds.  Extend this to the other 10 billion
data types around right now, and there's an enormous difference
between what we have now and OpenDoc.

>Why wait for OpenDoc?
>
>Oh (he says) you want to do some form of dynamic update from your Cray?
>(Like there are thousands of business users out there who have Crays
>they are just dying to incorporate animations from.)
>
>Then just make your simulation package compatable with publish and subscribe.

Publish and subscribe doesn't do 1/10th of the things OpenDoc does.
I'm assuming you're playing devil's advocate here.

>OpenDoc does not allow you to do things you couldn't before, (like
>dynamic update); it only allows you to create compound documents which
>change the menu bar and the tools (and underlying executing application part)
>when you click on part of a compound document.

>Just like OLE v2.0, it does *not* add features that cannot be added today,
>except for the compound document user interface. (That is, the only thing
>it eliminates is the major task swap and reshuffling of windows--this
>is replaced by a major task swap when you select the picture you
>put into your text document.)

I would argue that's quite a lot, but that's hardly where OpenDoc
ends.  Can you send AppleScript commands to edition containers?
Can you have real-time updates on edition containers?  Can you (usefully)
subscribe to a data type you never knew about.  Can you grab
a document with a lot of subscriptions, bring it over to another
computer, and start editting it there, without needing to bring
over all the miscellaneous edition files.

Publish and subscribe is and will always be a clumsy interface.
It was a great idea for it's time, but lets not exaggerate
it's capabilities.

>If we really wanted, needed, and required dynamic update of documents,
>or any of a half-dozen other features that OpenDoc is being touted for,
>we _could_have_done_it_already, with AppleEvents and Publish and Subscribe.
>(Which have been around for over 2 _years_ now.)

Yes, we could have, but it would have been one hell of a lot
harder.  Kind of like arguing, "The Mac's no big deal, I could
have written it on top of DOS."  We know what a dumb idea that
is...
--
Adam Winer
[e-mail]
If Oracle has any opinions, these aren't them.

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Tue, 27 Jun 1995 03:56:57 -0800
Organization: In Phase Consulting

[e-mail] (Jerome Jahnke) wrote:

> > Or QuickDraw GX.
>
> How does QuickDraw GX compare to OpenDoc? Personally I don't use it, but
> then I got 4 years worth of 3D graphics code sitting on my disc that does
> not use much at all of the MacToolbox. However I am considering QuickDraw
> 3D for new stuff if only becuase it will give me access to hardware
> support for 3D as it becomes available on the mac.

A gentle reminder.

QuickDraw GX was advocated as a cutting-edge technology to allow the
easier creation of applications which provide typesetting services.
The add-on market then was endless; it would make it infinitely easier
to produce page layout programs, typesetting programs, and would allow
greater flexability in page layout.

It was the major technological advance which would make things easier
than ever for developers, allow significant after-market opportunities,
and it would clean windows, too. (Or at least clean Microsoft Window's
clock.)

In fact, much of the hype sounded pretty much the same. Or at least
enough the same that I actually invested a fair amount of time figuring
out exactly what QuickDraw GX was. And to be honest, it was a wonderful
technological advance that was never needed by the market.

                                                        - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Tue, 27 Jun 1995 04:06:15 -0800
Organization: In Phase Consulting

> Once upon a time, some company found itself with a new technology, the
> "dry photocopy process".  The company decided to do some market research
> to decide if it could exploit this technology.  It did a market survey
> based upon the closest competing technology: carbon copies.  It discovered
> that carbon copies weren't used very often, from which they concluded that
> the dry photo copy process would never yield a significant profit.  They
> therefore sold the technology to some fledgling little company.

I know that story. It's a wonderful story, full of interesting points
about the fact that sometimes you need to take a risk with a new
technology, because often your marketing people are wrong.

And for every one of those, there are hundreds, if not thousands, of
stories where the moral of the story is:

        "And the fledgling little company sank into the black,
         never to be heard from again."

Look, I have nothing against OpenDoc. And, to be honest, I'm spending
a lot of time trying to figure out what OpenDoc is about, and in my
spare time I'm learning how to write software for OpenDoc.

Why?

Because I could be wrong. And because it doesn't cost me anything to
spend some time learning a new technology.

However, I honestly don't believe this technology is going to take
off in the ways that everyone is daydreaming about. And honestly I
don't think it's going to live up to the high expectations that people
have of the technology.

And because I believe that an honest and reasonable analysis of
the market forces that are currently under way would reveal that all
of the hopes (OpenDoc as a superior replacement for Visual Basic for
Windows?) and dreams (filter components which mediate sending e-mail?)
won't make a significant impact in the overall shape of the market.

                                                        - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Tue, 27 Jun 1995 04:08:00 -0800
Organization: In Phase Consulting

[e-mail] (Jim Lloyd) wrote:

> In article <3sn8nc$[e-mail]>, Karl Armstrong
> <[e-mail]> got his attributions wrong:
>
> >Jim Lloyd wrote:
>  ^^^^^^^^^
> >>>Look at me--I do games.
>
> No, I didn't say the above. William Edward Woody said it.

Am I so antisocial now that no-one wants anything to do with the things
I say?

*giggle*

Remember the first rule of debate: never confuse the devil's advocate
for the devil himself.

                                                        - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (Laurent Humbert)
Date: Tue, 27 Jun 1995 13:43:46 +0000
Organization: SW15 Software

>[OpenDoc ?]

OpenDoc is yet another insanely great new technology by Apple, supposed to
change life as we know it.

But it's not funny any more....

FWIW, I'll probably invest more time learning Win95/MFC/OLE rather than
ODF.




+++++++++++++++++++++++++++

>From [e-mail] (Christian E. Hopps)
Date: Tue, 27 Jun 1995 10:13:02 -0400
Organization: Eastern Michigan University, Ypsilanti

In article <woody-2706950406150001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:
> However, I honestly don't believe this technology is going to take
> off in the ways that everyone is daydreaming about. And honestly I
> don't think it's going to live up to the high expectations that people
> have of the technology.

I get the same feeling.  Except in my case I haven't done much research.

I keep getting this image of a user sitting in front of a computer
with 16 manuals strewn about.  A big question mark floats over the
users head as the user tries to figure out where to get help.

Another related image I have is of a responsibility nightmare.  Everyone
keeps referring to these companies who will be packaging a collection
of parts to make a general application.  What happens when some of the
parts are buggy?  I do understand its easier for the user to get it
fixed (replace buggy parts).  So the user calls the "collection company"
and they supposedly work with all the part creators to locate the bug.
Something tells me there are a lot of communication links that can break
down here.

What about companies that are expected to actually write the parts?  I
think a very common feeling among development firms is that they must
have control over what they release.  That is if something is wrong they
want to fix it.  A good example of what can go wrong (and what I am saying
developers may be afraid of) is the debugservices-[compilervendor]debugger-
ram doubler escapade.  I sat and watched metrowerks (and to a lesser degree
symantec) get a bunch of news posts asking why the debugger didn't work
under system 7.5.1.  The generic answer was:  Its not us its company X.
Users have a way of getting annoyed with that answer no matter how true
it is.

Consider a slightly different problem with the current
[compiler vendor]debugger-debug services setup.  I occasionally see a user
ask for [compiler-vendor] for a specific addition that would be useful to
add to the debugger to which the reply is that for now debug-services
doesn't currently support that.  That is the user identifies company A
as the one to ask for the addition when its really company B they should
be asking.  Again the result is: Its not us you need to ask company B.

Now consider N companies with company 1 supplying a part/container and
companies 2 through N supplying the market with a needed second part
to make the overall product useful.  A user requests company A add a
feature and the feature really belongs to the secondary part.  Except now
we have a new problem the market for parts 2,N is much larger than this
specific product and companies 2,N don't see a need to add this feature.
Company 1 and the user of this product are basically out of luck.

I guess this boils down to: I feel anxious over the expected amount
of implicit inter-dependence among developer firms that OpenDoc seems
to require and expects to create.

Actually there is a really good model of this.  Consider an application
framework or even just a OO application where most of the functionality
has been factored into separate objects.  You decouple the functionality
of one thing from others to make it more useful -- this sounds like what
OpenDoc is supposed to do.  However, as anyone who has done this knows,
the semantics of object interaction becomes harder to document, maintain
and learn. Overall complexity increases.  This is an okay situation for a
programmer (or team) because their main goal is then to keep things well
documented and in sync with the main design, i.e. constantly work at
avoiding entropy.  What I am getting at above is that with OpenDoc there
is no programmer or team in charge of keeping sanity.  Yes some people
may step into the role but it is not at the same (and possibly needed)
level.  In the end the users really plays the role of "the invisible glue".
Left to itself I wonder if the market won't diverge into chaos.

Sounds scary.

Chris.

PS Don't misunderstand me, as a power user I think OpenDoc sounds cool.  I
would love to be able to move my Mac vim code into a part and use it
in all my editors.

+++++++++++++++++++++++++++

>From [e-mail] (Paolo G. Cordone)
Date: Tue, 27 Jun 1995 18:46:03 +0100
Organization: P&P

In article <woody-2506951647480001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> The upshot of this is that OpenDoc, while a wonderful new programming
> and user interface paradigm, probably won't affect many of us
> on the net. Unless we really do put together complex, compound
> documents for a living.

Oh yes? Never heard of Cyberdog, then?

Paolo

======================================================================
Paolo G. Cordone         |             Ailesbury Rd. Dublin 4, Ireland
Macintosh                |  Internet:  [e-mail]
software engineer        |             [e-mail]
& localization           |    OneNet:  ClubMac_Ireland, [phone]
specialist               |      http://intac.com/~gilesrd/paologc.html
======================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Paolo G. Cordone)
Date: Tue, 27 Jun 1995 18:46:04 +0100
Organization: P&P

In article <[e-mail]>,
[e-mail] (John Nagle) wrote:

>     As a final nail in the coffin, the usual suggestion for "compound
> documents" involves tying together spreadsheets and word processor documents.
> And who makes the leading spreadsheet and the leading word processor for
> the Mac?  Microsoft.  Are they going to support OpenDoc?  No.

But why are you only considering things like writing papers and doing
layout jobs? OpenDoc will also address editors for the most different
tasks, like reading usenet, personal email and WWW.
Example, you have a container filled with text, you want to send that text
as mail. All you would have to do is to drag a 'mailer' stationery into
that container and there you go. A simple text file has been converted to a
mail which can be sent.
Something like that.

Paolo

======================================================================
Paolo G. Cordone         |             Ailesbury Rd. Dublin 4, Ireland
Macintosh                |  Internet:  [e-mail]
software engineer        |             [e-mail]
& localization           |    OneNet:  ClubMac_Ireland, [phone]
specialist               |      http://intac.com/~gilesrd/paologc.html
======================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Tue, 27 Jun 1995 19:12:24 GMT
Organization: BSD -- Academic Computing

In article <woody-2706950356570001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> [e-mail] (Jerome Jahnke) wrote:
>
> > > Or QuickDraw GX.
> >
> > How does QuickDraw GX compare to OpenDoc? Personally I don't use it, but
> > then I got 4 years worth of 3D graphics code sitting on my disc that does
> > not use much at all of the MacToolbox. However I am considering QuickDraw
> > 3D for new stuff if only becuase it will give me access to hardware
> > support for 3D as it becomes available on the mac.
>
> A gentle reminder.
>
> QuickDraw GX was advocated as a cutting-edge technology to allow the
> easier creation of applications which provide typesetting services.
> The add-on market then was endless; it would make it infinitely easier
> to produce page layout programs, typesetting programs, and would allow
> greater flexability in page layout.

And it has not been out for public consumption for very long either. If
you want to compare it on the merits of the other three (Publish and
Subscribe, Apple Events, and Apple Script) which have been out for quite a
bit longer. AppleScript is the newest of the three and has caught on in a
very short period of time. As developers adopt products folks use them. As
I said, I personally have no use for typography. GX's largest problem to
date has been it's phenomonal slip. When I was working for AlphaGraphics
in the late 80's GX was slated to be part of the impending system 7
release. At that time I was concerned with Typography, here it is over 5
years later and GX has arrived.

> It was the major technological advance which would make things easier
> than ever for developers, allow significant after-market opportunities,
> and it would clean windows, too. (Or at least clean Microsoft Window's
> clock.)

I hve never stated that any Apple Technology will clean Microsofts clock.
That job is left to developers NOT folks that write OS's. People don't buy
computers becuase OS x is better than OS y. They buy them becuase they
have software that runs great under OS x, as opposed to OK under OS y.

> In fact, much of the hype sounded pretty much the same. Or at least
> enough the same that I actually invested a fair amount of time figuring
> out exactly what QuickDraw GX was. And to be honest, it was a wonderful
> technological advance that was never needed by the market.

You seem to be able to accurately peg markets before they have a chance to
develop. As I stated QuickDraw GX has been out for less than a year now.
And it is making inroads. I would not count it all the way out yet. I read
in MacWeek every few weeks that some company or another is going to write
their next app wiht GX. This coupled with the fact that lotsa folks have
lots of inherited code that does lots of what GX does which gives them
less impetious to move to GX. But new product seem to be coming out that
suppor it, it makes development time shorter.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Tue, 27 Jun 1995 12:29:26 -0800
Organization: In Phase Consulting

In article <[e-mail]>, [e-mail]
(Laurent Humbert) wrote:

> >[OpenDoc ?]
>
> FWIW, I'll probably invest more time learning Win95/MFC/OLE rather than
> ODF.

And the really cool part is that if you write your application under
the MFC framework, you get Macintosh compatability for free.

(Just like OpenDoc. Er, hang on a sec'; wasn't that one of the Big
Deals that OpenDoc gave you that you couldn't get anywhere else?
Hmmmm. Gotta rethink that one, should we.)

                                                        - Bill

Who refuses to sing "Cumbya, My Lord" in union with everyone else,
even if the leader of the band is his favorite computer company, Apple.

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Tue, 27 Jun 1995 12:33:17 -0800
Organization: In Phase Consulting

[e-mail] (Paolo G. Cordone) wrote:

> [e-mail] (William Edward Woody) wrote:
> > The upshot of this is that OpenDoc, while a wonderful new programming
> > and user interface paradigm, probably won't affect many of us
> > on the net. Unless we really do put together complex, compound
> > documents for a living.
>
> Oh yes? Never heard of Cyberdog, then?

Yes I have, and it's the coolest thing in the world! It'll allow
us to do things we *never* have done before, like, er, post news,
and like, ummmm..., send e-mail, and even, er, ah, read Web pages,
hmmmmmmmm...

*sigh*

What was Cyberdog again?

And what was so insanely special about it that I can't already do with
a half a dozen other programs (aside from it's technological coolness
and the fact that it is written as separate components inside an OpenDoc
framework)?

                                                - Bill

The dont_impress_me_with_technology,_show_me_what_I_can_get_done_with_it
sorta guy.

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (J. Taggart Gorman)
Date: Wed, 28 Jun 1995 00:53:08 GMT
Organization: Scopus Technology, Inc.

In article <woody-2706951229260001@192.0.2.1>, [e-mail] (William Edward Woody) writes:
>In article <[e-mail]>, [e-mail]
>(Laurent Humbert) wrote:
>
>> >[OpenDoc ?]
>>
>> FWIW, I'll probably invest more time learning Win95/MFC/OLE rather than
>> ODF.
>
>And the really cool part is that if you write your application under
>the MFC framework, you get Macintosh compatability for free.

  I'm not going to hop in on the OpenDoc thread, but I will make nasty noises
at Bill's statement of "Macintosh compatability for free".

  I take it you've never actually used the Visual C++ cross compiler, eh?
If you have, and you've gotten your MFC app to work for free, then either the
app you compiled must have about 10 lines of code, or you got a better cross
compiler than me.  ;)

  VC Cross Compiler for Macintosh is an insult.  I won't say anything more.

>Who refuses to sing "Cumbya, My Lord" in union with everyone else,
>even if the leader of the band is his favorite computer company, Apple.

  Hey, if everyone agreed on everything, we'd still be using MS-DOS.  (Well,
DOS is still good for Doom...)

- -
J. Taggart Gorman
[e-mail]
All Hail BEPPE, the "New Age" God of Computers for the 3rd millenium!



+++++++++++++++++++++++++++

>From [e-mail] (Jim Lloyd)
Date: Tue, 27 Jun 1995 21:00:58 -0700
Organization: MelonGem Productions

In article <woody-2706950406150001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

>Look, I have nothing against OpenDoc. And, to be honest, I'm spending
>a lot of time trying to figure out what OpenDoc is about, and in my
>spare time I'm learning how to write software for OpenDoc.
>
>Why?
>
>Because I could be wrong. And because it doesn't cost me anything to
>spend some time learning a new technology.
>
>However, I honestly don't believe this technology is going to take
>off in the ways that everyone is daydreaming about. And honestly I
>don't think it's going to live up to the high expectations that people
>have of the technology.
>
>And because I believe that an honest and reasonable analysis of
>the market forces that are currently under way would reveal that all
>of the hopes (OpenDoc as a superior replacement for Visual Basic for
>Windows?) and dreams (filter components which mediate sending e-mail?)
>won't make a significant impact in the overall shape of the market.

Ok, I won't argue against this opinion.  I agree that market forces can
sometimes turn technically superior products into failures, and it's too
soon to tell what the market will do with OpenDoc.  However, you're
initial arguments seemed to be on the level of "OpenDoc is just a compound
document architecture, which we already have, and nobody uses, because
there is no need".  Even Microsoft doesn't use this kind of argument
against OpenDoc.

- ---------------------------------------------------------------------
Jim Lloyd                                              [e-mail]
Software Consultant                                     v. 415-964-8500
MelonGem Productions                                    f. 415-964-6888
                 "At our convenience, at your expense."

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Wed, 28 Jun 1995 05:56:34 GMT
Organization: BSD -- Academic Computing

In article <woody-2706951229260001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> In article <[e-mail]>, [e-mail]
> (Laurent Humbert) wrote:
>
> > >[OpenDoc ?]
> >
> > FWIW, I'll probably invest more time learning Win95/MFC/OLE rather than
> > ODF.
>
> And the really cool part is that if you write your application under
> the MFC framework, you get Macintosh compatability for free.

Come ON! You are banging Apple Evangalism for their stance on OpenDoc and
you say something like this?? Have you #1) Tried to do this (MFC program
under both Mac and Windows) and #2) Seen the results of such efforts??
Seems to me you are doing our devils advocating a bit more than necessary
here. There are serious problems with MFC on the Mac side, the least of
which seems to be a severe memory leak. Now I will say that MFC is a
rather nice Windows lib, however I like OWL better, it is more my flavor,
kinda like PowerPlant vs MacApp. MFC is more like MacApp, and OWL is more
like PowerPlant.

> (Just like OpenDoc. Er, hang on a sec'; wasn't that one of the Big
> Deals that OpenDoc gave you that you couldn't get anywhere else?
> Hmmmm. Gotta rethink that one, should we.)

OpenDoc is cross platform. And ODF is more so. Both are out and working.
No amount of cross platform work will EVER be one source file will compile
for both platforms.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Tue, 27 Jun 1995 20:17:28 -0800
Organization: Oracle Corp.

In article <woody-2706951229260001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

>In article <[e-mail]>, [e-mail]
>(Laurent Humbert) wrote:
>
>> >[OpenDoc ?]
>>
>> FWIW, I'll probably invest more time learning Win95/MFC/OLE rather than
>> ODF.
>
>And the really cool part is that if you write your application under
>the MFC framework, you get Macintosh compatability for free.

You don't really believe this, do you?  Even Microsoft doesn't claim
that you can use Wings, switch to the Mac target, and get anything
even remotely good enough for a commercial app.  Performance,
look-and-feel, and feature set (both on the Windows side and Mac
side) of VC++-ported apps just don't cut it without some serious
direct-to-Toolbox hacking.  Hell, I've even been told by MS employees
to avoid using VC++/Wings/MFC if at all possible.

Seriously, Bill, you don't have to sing "Cumbaya" with us,
but you also don't have to wield a pitchfork!
--
Adam Winer
[e-mail]
If Oracle has any opinions, these aren't them.

+++++++++++++++++++++++++++

>From [e-mail] (Jim Matthews)
Date: Wed, 28 Jun 1995 10:01:07 -0500
Organization: Dartmouth College

In article <woody-2706951233170001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> What was Cyberdog again?
>
> And what was so insanely special about it that I can't already do with
> a half a dozen other programs (aside from it's technological coolness
> and the fact that it is written as separate components inside an OpenDoc
> framework)?

Off the top of my head:

* It keeps a unified log and hotlist that is shared between my FTP client,
gopher client, web browser, etc., without limiting me to software from one
company.

* It lets me put real Internet data, as opposed to an ugly URL that must
be copy/pasted or cmd-clicked, in arbitrary documents.

* It lets me enhance my browsers incrementally.  If I want my web browser
to have VRML support I don't have to wait for my browser vendor to get
around to it, or for someone else to implement the union of the browser
features I like and VRML; I just have to wait for someone to write a VRML
part.  Today I can't get inline JPEGs without ditching MacWeb for
Netscape; with Cyberdog I can choose software with finer granularity.

* It lets me keep writing Internet software.  For example, I wrote and
maintain an Internet e-mail program.  These days, an e-mail program should
allow the inline viewing and editing of any sort of content that has a
MIME type assigned.  But there's no way I can do that, and with today's
technology I can either give up or do a half-baked job.  With OpenDoc
there's an opportunity to harness viewers and editors written by others,
without giving up the features of my e-mail program that I want to keep.
And it's a much saner approach to software engineering: enhancing the
program to support a new data type won't require new releases, new testing
cycles, etc.  OpenDoc could let me get off the upgrade treadmill without
leaving my program to stagnate.

To me OpenDoc feels a lot like the Mac Toolbox did in 1984.  It was a lot
to get your mind around, and made programming an order of magnitude
harder.  A devil's advocate could easily ridicule the payoff from all this
trouble: what makes a Mac menu so much more powerful than the ones in the
DOS version of 1-2-3?  But in the final analysis the Toolbox made it
possible to write programs that we just couldn't have written under DOS,
and we're the better for it.  OpenDoc may not slay Microsoft, but in 5-10
years I suspect that non-component software will look like DOS software in
the early 90s; it just won't seem right.  After seeing Cyberdog at WWDC my
reaction was "Why isn't the Copland Finder a Cyberdog part?"  The Copland
Finder looks to be an amazing program, but once you get the OpenDoc bug it
seems awfully limiting to bottle up that functionality in a single
application.

Jim Matthews
Dartmouth Software Development
<http://www.dartmouth.edu/pages/softdev/>

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Wed, 28 Jun 1995 13:38:17 -0800
Organization: In Phase Consulting

In article <[e-mail]>, [e-mail] wrote:

>   I take it you've never actually used the Visual C++ cross compiler, eh?
> If you have, and you've gotten your MFC app to work for free, then either the
> app you compiled must have about 10 lines of code, or you got a better cross
> compiler than me.  ;)

Ah, yes; let's all pull out our programming phallises and see which one
is longer. (10 lines of code? Yeah, right...)

Look, _nothing_ is for free. Even portability when writing code with
OpenDoc is not for free; not by any stretch of the imagination. And
the Microsoft Visual C++ cross compiler environment for the Macintosh
really sucks big time; it produces lousy code, and the MFC framework
is a real loser, in my book. (Not that it's from Microsoft you understand;
but because technically it bites big time.)

On the other hand, with some of the discussion about how wonderful
OpenDoc is because it provides 'portability for free'--first, it's
not the only tool out there claiming that, and second, portability
does not come for free by any stretch of the imagination. And frankly,
like MFC, OpenDoc may not even be the right answer for portability.
(Depends on how Novell does in it's port to Windows.)

                                                - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Wed, 28 Jun 1995 13:58:07 -0800
Organization: In Phase Consulting

[e-mail] (Jim Lloyd) wrote:

> Ok, I won't argue against this opinion.  I agree that market forces can
> sometimes turn technically superior products into failures, and it's too
> soon to tell what the market will do with OpenDoc.  However, you're
> initial arguments seemed to be on the level of "OpenDoc is just a compound
> document architecture, which we already have, and nobody uses, because
> there is no need".  Even Microsoft doesn't use this kind of argument
> against OpenDoc.

Nice summary. However, you got it wrong.

However, let *me* summarize what *I* am saying.

1)  "OpenDoc is wonderful because it provides hot links and on-the-fly
    updates across multiple applications."

me: If hot-links were so darned important and so darned cool, then why
    wait for OpenDoc? Use Publish and Subscribe.

    If people aren't using Publish and Subscribe, then perhaps it's because
    hot-links are not all that hyper-special and cool.

2)  "OpenDoc provides wonderful interapplication interaction."

me: If interapplication interaction was do darned cool, then why wait
    for OpenDoc? Use AppleEvents.

    If people aren't using AppleEvents, then perhaps it's because
    interapplication interaction is not all that hyper-special and cool.

3)  "OpenDoc provides a compound docoument-centric interface that's really
    cool."

me: (Note: I never said compound documents are already here.)

    That's really a neat idea. However, compound documents are only
    really useful in the standard business applications--spreadsheets,
    word processors, project management, etc.

    Those markets are already fully saturated by the big players, with
    Microsoft being the biggest.

    Is OpenDoc going to help us put together really cool business
    applications? Yes. Will we see any revenue or return from our
    programming investment from putting together really cool business
    applications? Only if Microsoft (or another big player already in
    this fully saturated market) picks up the tool and puts into a
    new revision of their product.

4)  I have been told by some at Apple that "OpenDoc is the Microsoft
    Killer." (That's why Microsoft is trying to kill OpenDoc.) That is,
    "OpenDoc will allow smaller software developers to effectively pick
    Microsoft's choakhold on the business software market apart."

me: People do not buy individual software tools. They buy pre-packaged
    software packages. (That's why Microsoft Office is so darned
    successful--a one stop solution.)

    So, we basically reduce this argument to the same as for #3, above.



Now, since making my initial arguments, I have had a number of issues
brought to my attention. And I honestly do not know enough about the
heart of the OpenDoc API to be able to make a reasonable judgement if
what I am being told is hype or honest truth.

Those people have basically responded to arguments (1) and (2) above:

1a) People didn't use Publish and Subscribe, not because on-the-fly
    updates isn't cool, but because Publish and Subscribe sucks.
    OpenDoc allows us to do Publish and Subscribe-like things in a
    much easier and more natural way.

2a) People didn't use AppleEvents, not because interapplication linking
    isn't cool, but because AppleEvents sucks. (Agreed, BTW.) OpenDoc
    allows us to do interapplication linking-like things in a much
    easier and more natural way.

Now I've gotten one interesting bit of e-mail which suggested that
OpenDoc, like any good paradigm shift, makes things hard at first (because
you need to bend your brain to fit into the new paradigm).  I have
nothing against bending my brain (it's good to occassionally crack the
crust off your brain by twisting it), and so the paradigm shift
doesn't really bother me. But on the other side, the question in my
mind still stands:

    Does OpenDoc really make interapplication operation and Publish-
    and-Subscribe easier?

There are two issues which surround this, which I need to answer for
myself.

The first is: when getting multiple applications to work together, they
must agree on what they are talking about in the first place. (It would
make no sense for a mail-tool to ask Micrsoft Excel to e-mail an outgoing
message, would it?) Does OpenDoc mediate this? How? And does OpenDoc
define the standards two applications use on having a conversation?

If so, then doesn't this also constitute an added level of complications?
(A good level which we need, regardless if OpenDoc takes off or not.)
If not, then how are we supposed to get our applications to work
together? (Shucks we can't even have a conversation about OpenDoc
before some wise-ass (me) gets in there and pisses people off!)

The second is: when getting on-the-fly updates to work, I do know that
applications can default to sending raw pictures and text if they
cannot mediate on a common specification language for those updates.

Does OpenDoc define other types of conversations? Or is that up to us?
(Basically it's the same question as above, except for applying to
imbeded applications.)


Well, I'm off to read the API specifications.

                                                - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (Mike Alexander)
Date: Wed, 28 Jun 1995 18:15:02 -0400
Organization: University of Michigan

In article <[e-mail]>,
[e-mail] (Jim Matthews) wrote:

> In article <woody-2706951233170001@192.0.2.1>,
> [e-mail] (William Edward Woody) wrote:
>
> > What was Cyberdog again?
> >
> > And what was so insanely special about it that I can't already do with
> > a half a dozen other programs (aside from it's technological coolness
> > and the fact that it is written as separate components inside an OpenDoc
> > framework)?
>
> Off the top of my head:

I agree with all you said, but one thing you left out is that it will let
ordinary people create customized documents which contain elements that
access the net.  You don't really need to know much about the net to do
this, and the person using the document doesn't really even need to know
the net exists.  They just know (to pick a random example) that the
document contains a description of some companies and also happens to
contain their current stock prices (or buttons to get them).  This is just
the first thing that comes to mind, lots more interesting and complex
examples are possible.  Sure it's possible to do this sort of thing now,
but it will be a heck of a lot easier with Cyberdog and similar things.

Mike Alexander              Internet:       [e-mail]
University of Michigan      America Online: MAlexander
ITD - Research Systems      AppleLink:      UMICH

+++++++++++++++++++++++++++

>From Richard Wesley <[e-mail]>
Date: 29 Jun 1995 15:41:53 GMT
Organization: Punch Deck Consulting

[e-mail] (Jerome Jahnke) wrote:
>In article <woody-2706951229260001@192.0.2.1>,
>[e-mail] (William Edward Woody) wrote:
>> And the really cool part is that if you write your application under
>> the MFC framework, you get Macintosh compatability for free.
>
>Come ON! You are banging Apple Evangalism for their stance on OpenDoc and
>you say something like this?? Have you #1) Tried to do this (MFC program
>under both Mac and Windows) and #2) Seen the results of such efforts??
>Seems to me you are doing our devils advocating a bit more than necessary
>here. There are serious problems with MFC on the Mac side, the least of
>which seems to be a severe memory leak. Now I will say that MFC is a
>rather nice Windows lib, however I like OWL better, it is more my flavor,
>kinda like PowerPlant vs MacApp. MFC is more like MacApp, and OWL is more
>like PowerPlant.

Not to mention massive code bloat.  I just talked to a group at Microsoft
who gave up using MFC/Mac because a vanilla application was 1Mb before they
added their own code!

http://www.punchdeck.com/hawkfish/Resume.html

- --------------------------------------------------------------------------
Richard Wesley  [e-mail] | "'Hand it round first, and cut it
Punch Deck Consulting [e-mail] |  afterwards.'" - Lewis Carroll,
     Macintosh Software Development    |    "Through the Looking Glass"
- --------------------------------------------------------------------------



+++++++++++++++++++++++++++

>From [e-mail] (Paolo G. Cordone)
Date: Thu, 29 Jun 1995 18:20:52 +0100
Organization: P&P

In article <[e-mail]>,
[e-mail] (Laurent Humbert) wrote:

> OpenDoc is yet another insanely great new technology by Apple, supposed to
> change life as we know it.
>
> But it's not funny any more....
>
> FWIW, I'll probably invest more time learning Win95/MFC/OLE rather than
> ODF.

Mmm, that sounds to me like in a year's time we (Mac users) we'll have to
wait for a Windoze version of NewsHopper to come out first before the same
version ships for the Mac...

To be honest it is a bit like a slap in the face. After supporting a Mac
only product and make it successful we are told that the developers now
will rather concentrate on MS technologies than adopting Apple's latest
innovations.
Pity.

Paolo

======================================================================
Paolo G. Cordone         |             Ailesbury Rd. Dublin 4, Ireland
Macintosh                |  Internet:  [e-mail]
software engineer        |             [e-mail]
& localization           |    OneNet:  ClubMac_Ireland, [phone]
specialist               |      http://intac.com/~gilesrd/paologc.html
======================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Paolo G. Cordone)
Date: Thu, 29 Jun 1995 18:20:54 +0100
Organization: P&P

In article <woody-2706951233170001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:

> Yes I have, and it's the coolest thing in the world! It'll allow
> us to do things we *never* have done before, like, er, post news,
> and like, ummmm..., send e-mail, and even, er, ah, read Web pages,
> hmmmmmmmm...

Why, then, do you have a computer? It allows you to do things we *never*
have done before, like, er, write memos, letters, do calculations, and all
sorts of things we have done for decades without computers.

It's not *what* we can do, it's *how* we can do which matters.

IMHO at least.

Paolo

======================================================================
Paolo G. Cordone         |             Ailesbury Rd. Dublin 4, Ireland
Macintosh                |  Internet:  [e-mail]
software engineer        |             [e-mail]
& localization           |    OneNet:  ClubMac_Ireland, [phone]
specialist               |      http://intac.com/~gilesrd/paologc.html
======================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Gregory Jorgensen)
Date: Wed, 28 Jun 1995 14:10:27 -0800
Organization: Radix Consulting Inc.

In article <[e-mail]>,
[e-mail] (Jerome Jahnke) wrote:

> I hve never stated that any Apple Technology will clean Microsofts clock.
> That job is left to developers NOT folks that write OS's. People don't buy
> computers becuase OS x is better than OS y. They buy them becuase they
> have software that runs great under OS x, as opposed to OK under OS y.

If you believe this you have never spent any time in a computer store, or
working for a corporation with lame policies, or studying in a university
that's on the Apple or IBM dole. And no matter what we would all like to
believe, people don't think about whether their software (if they even
have any) will work on the PC they buy until they get it home. Price is a
big, if not the biggest, deciding factor in PC sales. Availability and
selection are probably the next biggest factor.

OpenDoc will matter to developers. It won't matter to end-users no matter
how cool it is. When we have software that will let someone "who doesn't
know computer" "punch a button" and "do a report and graph for them" then
we'll have something. And those users won't care who makes the box (as if
they do now). [The quotes are a composite of things I regularly hear from
clients.]

--
Gregory Jorgensen
radix consulting inc
[e-mail], [e-mail]

"I would consent to have a limb amputated to recover my spirits." -- Samuel Johnson

+++++++++++++++++++++++++++

>From Karl Armstrong <[e-mail]>
Date: 29 Jun 1995 17:38:58 GMT
Organization: Computing Devices Int.

[e-mail] (William Edward Woody) wrote:
>3)  "OpenDoc provides a compound docoument-centric interface that's really
>    cool."
>
>me: (Note: I never said compound documents are already here.)
>
>    That's really a neat idea. However, compound documents are only
>    really useful in the standard business applications--spreadsheets,
>    word processors, project management, etc.
>
>    Those markets are already fully saturated by the big players, with
>    Microsoft being the biggest.
>
>    Is OpenDoc going to help us put together really cool business
>    applications? Yes. Will we see any revenue or return from our
>    programming investment from putting together really cool business
>    applications? Only if Microsoft (or another big player already in
>    this fully saturated market) picks up the tool and puts into a
>    new revision of their product.

As I said before, early in this discussion, compound docs are not just for
business applications. It's not really that hard to image a game system
based on component software, where the player's environment is a kind of
"compound document". It's a new concept (at least for computer games) but
it something that should work naturally. It's also not too hard to think
of a software engineering project file (not the individual source files)
as a compound document; in fact all the current software development
systems depend heavily on IPC. A graphics package based on component
software already exists; it's called Photoshop.

It's hard to imagine M$ and the other big boys getting all the good
ideas, and even if they do there's a proven market for plug-ins (Photoshop)
that sets a good precedent for small OD developers.

Do existing solutions already exist?  Partially, but there is a mixture of
solutions (AppleEvents, Publish&Subscribe, Drag Manager, proprietary plug-ins,
etc...) and none of them are perfect. OD is a logical next step, and though
it won't ever be perfect either, it will give Apple an advantage.

--
Karl Arsmtrong
Computing Devices Int.
[phone]
[phone] (fax)


+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 02 Jul 1995 14:57:32 +0800
Organization: Department of Computer Science, University of Western Australia

In article <[e-mail]>,
[e-mail] (Jim Matthews) wrote:

>After seeing Cyberdog at WWDC my
>reaction was "Why isn't the Copland Finder a Cyberdog part?"

Well the simple answer to that is that the Gershwin Finder *will* be an
OpenDoc part.  I think Copland development is too far down the track for
such a crucial component to be dependent on a technology that isn't
finished yet.

Share and Enjoy.
--
Quinn "The Eskimo!"      "Space army! I'd death ray my grandmother
                          for a space army about now."
>From [e-mail] (eric larson)
Subject: Why fuss over OpenDoc?
Date: 01 Jul 95 09:39:42
Organization: FidoNet: No Microsoft Products Used To Produce This Message

 > People seem to be getting very excited about OpenDoc. Could someone
 > explain to a person like me (who doesn't create complicated documents
 > with charts and pictures) what there is to get excited about OpenDoc?

The main reason somebody like you would be interested in OpenDoc is that you
wouldn't have to carry around all the excess baggage that is present in a
modern monolithic program; say like Word 6. If all you need is a few simple
tools, that's all you would install.
>From [e-mail] (eric larson)
Subject: Why fuss over OpenDoc?
Date: 01 Jul 95 13:07:14
Organization: FidoNet: No Microsoft Products Used To Produce This Message

 > However, let *me* summarize what *I* am saying.

 > 1)  "OpenDoc is wonderful because it provides hot links and on-the-fly
 >     updates across multiple applications."

 > me: If hot-links were so darned important and so darned cool, then why
 >     wait for OpenDoc? Use Publish and Subscribe.

 >     If people aren't using Publish and Subscribe, then perhaps it's
 > because
 >     hot-links are not all that hyper-special and cool.

Or it might be because Publish and Subscribe is a bletcherous implementation of
hot links. Even the name makes one feel sort of woozy around the edges. Why
call it something impenetrable like "Publish and Subscribe" when it could be
called something like Hot Links? Similarly to QuickDraw GX. How can the user
grasp the benefits of a product with a name like that?

Seriously, the argument that a certain feature idea is bad because nobody uses
an existing implementation is very weak. There is a long history of success
following those who fix a broken implementation of a basically good idea.

It's like Intel stating that floating point isn't important because nobody uses
it. The real truth of the matter may be that nobody uses floating point on
Intel machines because Intel floating point bites.

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Mon, 03 Jul 1995 12:15:55 -0800
Organization: In Phase Consulting

[e-mail] (eric larson) wrote:

> Seriously, the argument that a certain feature idea is bad because nobody uses
> an existing implementation is very weak. There is a long history of success
> following those who fix a broken implementation of a basically good idea.

I know that. That's what I said at the bottom of the same post you just
quoted from.

The thing is, I had no idea how much other people disliked Publish and
Subscribe, or AppleEvents, until this thread was started and people
started blasting me.

> It's like Intel stating that floating point isn't important because
> nobody uses it. The real truth of the matter may be that nobody uses
> floating point on Intel machines because Intel floating point bites.

But I use floating point on Intel machines all the time. Code for it
in assembly language, I do. And while it's a little wierd, once you
get the hang of it Intel floating point is just fine.

See, that's my point. Until you told me that people don't write
floating point on Intel machines because it bit, I would have guessed
that most people don't do floating point on Intel machines because
they really didn't need floating point in their programming.
I would never have guessed that people didn't do floating point
because they disliked it so much.

                                                - Bill

--
William Edward Woody  |  e-mail: [e-mail]
In Phase Consulting   |  WWW:    http://www.alumni.caltech.edu/~woody
337 W. California #4  |  Fax:    [phone]
Glendale, CA 91203    |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (Stephen Marshall)
Date: Wed, 05 Jul 1995 10:52:27 +1200
Organization: Victoria University of Wellington

In article <3suofi$[e-mail]>, Karl Armstrong
<[e-mail]> wrote:

> [e-mail] (William Edward Woody) wrote:
> >3)  "OpenDoc provides a compound docoument-centric interface that's really
> >    cool."
> >
> >me: (Note: I never said compound documents are already here.)
> >
> >    That's really a neat idea. However, compound documents are only
> >    really useful in the standard business applications--spreadsheets,
> >    word processors, project management, etc.
> >
> >    Those markets are already fully saturated by the big players, with
> >    Microsoft being the biggest.

> As I said before, early in this discussion, compound docs are not just for
> business applications.

Absolutely, I can see a number of ways in which OpenDoc will be useful in
reseach environments, particularly when data analysis is involved standard
parts can handle display of graphs, tables and graphics while specialist
parts can do the actual analysis, given that research is fluid and the
objectives of the analysis software keep changing with the research, this
should lead to better software being used by more scientists and students.

I'm sure the same model can be applied elsewhere.

Stephen

--
Macintosh Consultant, Victoria University of Wellington, New Zealand
[e-mail]

It is not permitted for this message, in whole or in part,
to appear on The Microsoft Network or affiliated networks.

+++++++++++++++++++++++++++

>From [e-mail] (Matthew Inger)
Date: Wed, 5 Jul 95 16:24:15 GMT
Organization: Drexel University, Dept. of Math. and Comp. Sci.

eric larson ([e-mail]) wrote:
:  > However, let *me* summarize what *I* am saying.

:  > 1)  "OpenDoc is wonderful because it provides hot links and on-the-fly
:  >     updates across multiple applications."

:  > me: If hot-links were so darned important and so darned cool, then why
:  >     wait for OpenDoc? Use Publish and Subscribe.

:  >     If people aren't using Publish and Subscribe, then perhaps it's
:  > because
:  >     hot-links are not all that hyper-special and cool.

: Or it might be because Publish and Subscribe is a bletcherous implementation of
: hot links. Even the name makes one feel sort of woozy around the edges. Why

As opposed to Object Linking and Embedding?  Now there'es a really
friendly name for you.  I do agree however that's it's a pretty crappy
implemenatation, (Publish and Subscribe) and that OLE is superior here,
but OpenDoc will blow it away. Now both names are accurate, but neither is
friendly.
Publish and subscribe.  When you subscribe to a magazine, yhou get the latest
edition, when you reach in your magazine rack (or something like that).  Just
like when you subscribe to something on a mac, you get the latest version that
was published whenever you call up your document.
Object Linkning and Embedding.  OK>  You have your object (excel table as
an example), you link it or embed it into a document, it is now part of the
document. very  true to it's name.

Anyway, OLE is better for one big reason:
        1) Objects exist within the document that they are embedded in.  When
                you publish  and subscribe, you have to have a sepereate document
                for the object.  This can be good however, if more than on e
                doc is goign to use the exact same object.  But packages take
                care of this problem.

: call it something impenetrable like "Publish and Subscribe" when it could be
: called something like Hot Links? Similarly to QuickDraw GX. How can the user
: grasp the benefits of a product with a name like that?

PostScript?  There's another stupid name for you.  Think aobut it. Post=after,
Script=write.  After  writing?  Now that's dumb.

--
Matt Inger
[e-mail]
[e-mail]
http://www.mcs.drexel.edu/~uminger/
"Remember when you were young?  You shone like the sun."

+++++++++++++++++++++++++++

>From [e-mail] (Damon Cokenias)
Date: Wed, 05 Jul 1995 23:00:39 -0700
Organization: Mountain Palace

In article <[e-mail]>, [e-mail]
(Matthew Inger) wrote:

> PostScript?  There's another stupid name for you.  Think aobut it. Post=after,
> Script=write.  After  writing?  Now that's dumb.

I think PostScript is so called because it uses post-fix notation (aka
reverse Polish notation).

For example, the familiar MoveTo (100, 200) looks like this in PS:

100 200 moveto

It's much, much easier to parse (don't have to count parenthesis) and
arguably more difficult to program in.

-Damon

+++++++++++++++++++++++++++

>From Maynard Handley <[e-mail]>
Date: 6 Jul 1995 17:19:29 GMT
Organization: Apple Computer

it seems to me regrading OpenDoc, people are taking the ``Doc'' pat of
the name and the reltaed market hype too seriously and ignoring what it
seems the technology could achieve.
My hope is that OD will allow for a rather stronger separation between
the behvior of an app and the user interface of an app.
For example my app, Sparkle, is designed to play MPEGs on the mac. That's
what I really care about. But in addition to MPEG decoding, I have to
deal with all sorts of requests from users that are UI issues---for
example requesting a playback mode where all screens are blacked, the
menu bar hidden and one MPEG is played full screen.
Since this is basically a UI issue that is of no interest to me, it never
happens. I would hope that if my code were written as an OpenDoc part,
something like that would be handled by the overall app within whch I'm
embedded and I can ignore it.

This is part of a much wider issue. Consider all the different
translation/decoding apps out there, everyone with a different UI most of
which aren't great. Again maybe these thingswould be better in OD.

Now in many cases these things are best written as component software
within the existing component frameworks---maybe MPEG as a QT media
handler, or translation via Translation Manager. But in some cases no
such framework obviously exists---eg for decompression of .zip/arj/.gz
tyype docs. In other cases a framework is extant but too
limited, or difficult to develop and debug in. Regardless it seems to
me the hope is that OD provides yet another component software framework,
but one much richer than what we've had before and with the limitations
of the current systems examined and corrected.
With this viewpoint, issues like ``no-one uses publish&subsribe or
apple-events, or compound documents'' become irrelevant.

Maynard
>From [e-mail] (eric larson)
Subject: Why fuss over OpenDoc?
Date: 07 Jul 95 20:22:12
Organization: FidoNet: No Microsoft Products Used To Produce This Message

 > As opposed to Object Linking and Embedding?  Now there'es a really
 > friendly name for you.  I do agree however that's it's a pretty crappy
 > implemenatation, (Publish and Subscribe) and that OLE is superior here,
 > but OpenDoc will blow it away. Now both names are accurate, but neither
 > is friendly.

 > Publish and subscribe.  When you subscribe to a magazine, yhou get the
 > latest edition, when you reach in your magazine rack (or something like that
).

etc.. I'm sure that's how Apple justifies the name internally, too. But I think
it's poor. Too many syllables. Drag 'n Drop. Now you've got something even a
user can understand.

 > : called something like Hot Links? Similarly to QuickDraw GX. How can
 > the user
 > : grasp the benefits of a product with a name like that?

 > PostScript?  There's another stupid name for you.  Think aobut it.

The deal with Postscript is that you don't have to think about it. Buy the
Apple Laserwriter. Plug it in. Print. Do you see the word Postscript anywhere?
Maybe on the test page. Which was trashed long ago.

If OpenDoc makes the user think, it will flop. If not, it will be a big big
winner.

"Civilization advances by reducing the number of operations you have to think
about to get the job done".

This is why Apple is a 10 billion dollar company. It could be a lot bigger if
Apple knew how to sell.

+++++++++++++++++++++++++++

>From [e-mail] (Joshua Susser)
Date: Mon, 10 Jul 1995 18:46:05 GMT
Organization: Apple Computer, AppleSoft

Hi Bill.  It's good to see some thoughtful comments about OpenDoc here,
even if they are somewhat disdainful.  But I have enough confidence in
OpenDoc's technology and business planning that I think I can convince you
that we're not wasting our time here.

In article <woody-2806951358070001@192.0.2.1>,
[e-mail] (William Edward Woody) wrote:
> However, let *me* summarize what *I* am saying.
>
> 1)  "OpenDoc is wonderful because it provides hot links and on-the-fly
>     updates across multiple applications."
>
> me: If hot-links were so darned important and so darned cool, then why
>     wait for OpenDoc? Use Publish and Subscribe.
>
>     If people aren't using Publish and Subscribe, then perhaps it's because
>     hot-links are not all that hyper-special and cool.

OpenDoc improves on the Edition Manager in several ways.  The most
important one is that it has a much improved user interface.  It's just a
variation on "Paste" to create a link - no mucking about with edition
files.  At the programming level, linking is similar to copy/paste or
drag&drop - it all used the standard storage API for data transfer.  There
is some extra stuff you have to support for linking, and it's not
effortless to program, but it's not that awful either.

> 2)  "OpenDoc provides wonderful interapplication interaction."
>
> me: If interapplication interaction was do darned cool, then why wait
>     for OpenDoc? Use AppleEvents.
>
>     If people aren't using AppleEvents, then perhaps it's because
>     interapplication interaction is not all that hyper-special and cool.

But people are using Apple Events.  The Mac is the coolest netsurfing
platform in the universe, largely because of Apple Events.  For example,
in Newswatcher I can click on a URL and Netscape will go and browse that
page for me.  That kind of integration has become pervasive among Mac
Internet client software.  I agree that AppleScript hasn't become the
market-dominating behemoth it might have, but the technology there is
sound.  Check out the AppleScript infomercial sometime, and be very
impressed at what some publishing folks have done with it - they reduced
their catalog production process by something like two orders of magnitude
of time and effort, all with AppleScript automation.

But the big thing that OpenDoc will do for linking and interapp
interaction comes with the integration of the technologies into the
OpenDoc experience.  Linking and scripting will operate synergistically
with embedding and all the other OpenDoc features.  There will be no "now
I'm doing linking" mode change to think about.  You should be able to
create an index part that you can embed at the end of a document, that
uses scripting to generate an index from a list of words.  It would run
through the various parts in a document, and generate links back to the
occurances of the words, showing the keyword in context in the index
itself, keeping itself up to date automatically.

So no longer will linking and scripting be lone technologies.  They will
integrate into the total user experience, and so their value will be
increased from the synergy of that integration.

> 3)  "OpenDoc provides a compound docoument-centric interface that's really
>     cool."
>
> me: (Note: I never said compound documents are already here.)
>
>     That's really a neat idea. However, compound documents are only
>     really useful in the standard business applications--spreadsheets,
>     word processors, project management, etc.

Where did you get an idea like that?  Compound documents are useful for
all sorts of things.  Don't get fooled by the word "document" there - you
can build all sorts of things that don't fit into the traditional
definition of the term.  One thing I use my Mac for a lot is keeping a
database of my personal contacts.  It would be great to be able to embed
graphics like maps to houses, pictures, etc.  I'd also like to be able to
link Eudora's nicknames to an email address field in my database, so I
only have to keep that info in one place.  And I'd like to have CyberDog
links to home pages, etc. there as well.  Okay, admittedly I'm a power
user to the extreme, but you perhaps begin to get the idea.

Also think of scientific applications, visualization in particular.  Drop
some parts into a container, connect them together, and you have an
instant visualization system.  You can do this today with existing
systems, but they are all very specialized.  OpenDoc would enable that
kind of system, and include all the standard OpenDoc features as well.

>     Those markets are already fully saturated by the big players, with
>     Microsoft being the biggest.
>
>     Is OpenDoc going to help us put together really cool business
>     applications? Yes. Will we see any revenue or return from our
>     programming investment from putting together really cool business
>     applications? Only if Microsoft (or another big player already in
>     this fully saturated market) picks up the tool and puts into a
>     new revision of their product.

One thing OpenDoc will do is allow easy construction of custom solutions
from standard parts.  Imagine being able to produce software for a
vertical market of one, but with the functionality and robustness of
applications that are used by millions.  No, I don't envision my barber
going out and assembling his business software from parts, but I can see
him paying a small fee for a consultant to do that.  Then he'd have
exactly the software he'd need to keep a client list, schedule, product
inventory, and whatever - all integrated into a seamless whole.  This will
happen whether or not Microsoft or some other big player leads the way,
because of market evolution.

> 4)  I have been told by some at Apple that "OpenDoc is the Microsoft
>     Killer." (That's why Microsoft is trying to kill OpenDoc.) That is,
>     "OpenDoc will allow smaller software developers to effectively pick
>     Microsoft's choakhold on the business software market apart."
>
> me: People do not buy individual software tools. They buy pre-packaged
>     software packages. (That's why Microsoft Office is so darned
>     successful--a one stop solution.)
>
>     So, we basically reduce this argument to the same as for #3, above.

See my response above.  Yes, people don't buy parts and assemble them.
How many PC owners bought a motherboard, a power supply, a hard disk, etc.
and put them together?  We expect component software to sell the same way
as apps do today.  Instead of buying ClarisWorks or WordPerfect or
whatever as one app, I'll buy it as a bunch of parts.  It's no harder for
me to buy that way, and will probably cost the same, but upgrading the
drawing component will be much easier for both the developer and the
buyer.  And extending the existing "application" with new functionality
will also be easier.

So given that as the basic environment, imagine I'm a guy who has this
really cool equation editing software.  Right now, it would be hopeless to
try to sell a product based on that, because it's useless without the
whole word processor - nobody *just* want's to edit equations, they want a
equation here or there in some document - and there's no way I can compete
with Microsoft or whoever selling a word processor.  But with OpenDoc, I
can create an equation part editor which will work in any part that allows
embedding.  Suddenly I can sell my software and make money.  There are a
lot of questions about distribution channels to consider (will the
equation editor be sold stand alone, as part of a goodies package, over
the internet, or what?), but at least it's feasible to make money off the
thing.

> The first is: when getting multiple applications to work together, they
> must agree on what they are talking about in the first place. (It would
> make no sense for a mail-tool to ask Micrsoft Excel to e-mail an outgoing
> message, would it?) Does OpenDoc mediate this? How? And does OpenDoc
> define the standards two applications use on having a conversation?

There are two main mechanisms OpenDoc parts use to interoperate.  One is
scripting; this uses the standard terminology stuff to indicate
functionality.  The other is the Extension mechanism, which is lower level
and higher performance.  Extensions are classified by a standard naming
scheme.  CI Labs has ownership of the extension registry.  You don't have
to register a particular extension to get a name for it, but if you do,
other part developers will know about it and be able to use it.  If you
publish the specification, other developers can implement that extension
on their part editors, and your add-on will work with their parts.

> If so, then doesn't this also constitute an added level of complications?
> (A good level which we need, regardless if OpenDoc takes off or not.)
> If not, then how are we supposed to get our applications to work
> together?

This stuff doesn't seem very complicated to me, but then, I helped design
it.  Even so, the standard reaction from developers looking at Extensions
is "Cool!", not "Gee, this is complicated."  As for the higher-level issue
of designing solutions built from cooperating parts, well, if the internet
stuff we've seen on the Mac is a good example, or the Virtual Suite stuff
takes off, it will work pretty well.

> The second is: when getting on-the-fly updates to work, I do know that
> applications can default to sending raw pictures and text if they
> cannot mediate on a common specification language for those updates.
>
> Does OpenDoc define other types of conversations? Or is that up to us?

The OpenDoc storage format allows for writing multiple formats for a piece
of content.  So your word processor can save its own format, RTF and
ASCII, for example.  It might also save a PICT or bitmap if formatting is
important.  Multiple formats can be used not only for saving documents,
but also for data transfer, since clipboard/drag&drop/linking all use the
storage API for exchanging data.

The recipe goes like this: The source of the data transfer puts the
content on the data transfer draft in multiple formats, in order of
fidelity.  The destination scans through the formats in order they were
written, looking for a format it can accept.  If there are no formats that
can be merged with its own content, it will embed the content as a
separate part.  (The user also has explicit control over the decision if
desired.)  This applies to linking as well as moving or copying data.

> Well, I'm off to read the API specifications.

You mean you've been harping on OpenDoc all this time without any
background?  Well, once a Techer, always a Techer... :>

Joshua Susser, Object Contortionist
Apple Computer - OpenDoc Engineering
inet: [e-mail] | link: susser.j | phone: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Loren Petrich)
Date: Tue, 11 Jul 1995 20:19:29 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

        One last thing:

        When is OpenDoc supposed to be released? I know it's in beta, and
I've seen a MacWeek article suggesting some time in September, but I've
yet to see any official announcements from Apple about this. I wonder how
much longer OpenDoc will be in the limbo that Windoze 4.0 has been in?

--
Loren Petrich, the Master Blaster       Happiness is a fast Macintosh
[e-mail]                      And a fast train
Visit ftp://ftp.netcom.com/pub/pe/petrich
Or ftp to ftp.netcom.com, then go to /pub/pe/petrich

---------------------------

End of C.S.M.P. Digest
**********************